Yasuoka's hack log (2020年)
[ 2024 | 2023 | 2022 | 2021 | 2020 | 2019 | 2018 | 2017 | 2016 | 2015 | 2014 | 2013 | 2012 | 2011 ]
2020-12
2020-12-27: このサーバの時刻が狂っていた。M/B 交換した時に、全然時刻気にしてなかった...
2020-12-25: panic
panic: acquiring blockable sleep lock with spinlock or critical section held (rwlock) fbhlk Stopped at db_enter+0x10: popq %rbp TID PID UID PRFLAGS PFLAGS CPU COMMAND *192333 52311 5063 0x100001 0 3 sh 229879 14765 5063 0x100003 0x8 2K sh db_enter() at db_enter+0x10 panic(ffffffff81dfe083) at panic+0x12a witness_checkorder(ffff800000c27590,9,0) at witness_checkorder+0xb42 rw_enter_write(ffff800000c27580) at rw_enter_write+0x43 drm_fb_helper_restore_fbdev_mode_unlocked(ffff800000c27400) at drm_fb_helper_restore_fbdev_mode_unlocked+0x3c intel_fbdev_restore_mode(ffff8000002b5078) at intel_fbdev_restore_mode+0x33 db_ktrap(d,0,ffff8000243bf730) at db_ktrap+0x2c kerntrap(ffff8000243bf730) at kerntrap+0xa2 Xcalltrap_specstk_untramp() at Xcalltrap_specstk_untramp+0xf end trace frame: 0x0, count: 6 https://www.openbsd.org/ddb.html describes the minimum info required in bug reports. Insufficient info makes it difficult to find and fix bugs. ddb{3}>2020-12-25: バイト配列を用いたビットフラグを操作するライブラリ。少し 探してしまったが BSD の場合は libc だった https://man.openbsd.org/bit_ffs.3
2020-12-23: ランニングもプログラミングも同じで、この歳になると、リカバ リーが大変遅くなっている感じがする
2020-12-23: “Let’s use Kubernetes!” Now you have 8 problems 日本語訳: https://qiita.com/ITnews/items/cd806281afd1078841d7 、 多分あなたにKubernetesは必要ない
2020-12-21: このサーバへのリバースプロキシをやっているホストがメモリ不 足でハング。6.6 だったので、6.8 にアップグレードして様子見。アップグレー ドは数分で終わるけど、メモリ増量の影響で swap パーティションを増やした りしたり、/ パーティションが小さかったりして、ファイルシステムをリサイ ズした関係で 1 時間ぐらい断続的にダウン
2020-12-21: slack の Email App を使って シーマン の監視通知を slack のチャンネルにポストしているのだが、文章が化ける 上に、遅延があってダメダメ。文章化ける問題は Slack に問い合わせたりし ていたが、あらためて確認するとシーマンからのメールに Content-Type ヘッ ダがないので、シーマン側の問題。シーマンにフィードバックしようと思った けど、問い合わせ先が公開されていないっぽい..
2020-12-19: 2021年特別措置法の一部改正の対応 by yasuoka · Pull Request #9 · osamutake/japanese-holidays-js
2020-12-19: このサーバの母艦にヤフオクでゲットした Quad Port の Intel を装填完了。ケーブルもすべて取り替えた
2020-12-17: このサーバの母艦の補強。マザボ、CPU、RAM 交換。マザボは ASRock H410M-ITX/ac 、 CPU は Intel Core i5 10400、 RAM は 32GB。CPU のコア数が 2 → 6、RAM が 8GB → 32GB になった。しかし、 わざわざオンボード NIC が Intel なマザボにしたのにかかわらず、ESXi で 物理 NIC として認識させることが出来なかった。本当は RealTek にしておく ほうが無難なのかもしれない。
オンボード NIC は、I219-V (8086:0d55) というもの。vmware から ne1000-intelnuc というドライバが出ていてそれを使うと、I219-V は 認識されるものの、これを行った途端、外付けの Intel NIC (8086:10d3) が 認識されない問題を発症する。どちらも e1000 なので、両対応したデバド ラのほうに両方のデバイス ID からマッピングすれば動きそうなものだが、 数時間格闘しても、どちらか片方しか動かず、プロプライエタリなソフトウェ アをプライベート時間でハックするのはアホらしくなってやめた。ヤフオク で４ポートの Intel NIC (3000円) を即決で落札 。
試行錯誤のため、ESXi は最新の 7.0.1 になった。
事前に 自作PCにVMware vSphere Hypervisor (ESXi)をインストール - みかん のゆるふわ技術ブログ を軽く読んでいたのに、結局、まったく同じマザボを買って同じ問題を踏ん でしまったということになる...
2020-12-16: acpibat おかしい
Dec 16 07:55:40 yasuoka-ob1 apmd: system resumed from sleep Dec 16 07:55:40 yasuoka-ob1 apmd: battery status: high. external power status: not connected. estimated battery life 74% (4793 minutes) Dec 16 08:16:59 yasuoka-ob1 apmd: battery status: high. external power status: not connected. estimated battery life 64% (87 minutes) Dec 16 08:28:29 yasuoka-ob1 apmd: battery status: high. external power status: not connected. estimated battery life 54% (81 minutes) Dec 16 08:32:59 yasuoka-ob1 apmd: battery status: low. external power status: not connected. estimated battery life 50% (63 minutes) Dec 16 08:44:09 yasuoka-ob1 apmd: battery status: low. external power status: not connected. estimated battery life 40% (88 minutes) Dec 16 08:49:37 yasuoka-ob1 apmd: battery status: high. external power status: not connected. estimated battery life 60% (73 minutes) Dec 16 08:49:39 yasuoka-ob1 apmd: battery status: CRITICAL. external power status: not connected. estimated battery life 0% Dec 16 08:50:08 yasuoka-ob1 apmd: system hibernating
74%, 64, 54, 50, 40 と変化し、その 2 秒後が 60% になり、29 秒後に 0%。 AC に接続して OpenBSD で 36% ぐらいまで回復した時点で Windows で答え合わせしてみたが、正解だった。 再発したら、再発時に答え合わせをしてみよう。 そういえば、apmbat を無効にしていた時代も、battery が少なくなると、 CPU が低速になっていたので、apmd による CPU のパフォーマンス調整は要らないのかもしれない。
2020-12-16: 'py-rcsparse and python 3' - MARC このメール見落としてた。 cvs2gitdump の Python3 対応やらねば。
2020-12-17:
現在のバージョンを確認する:
[root@vm0:~] esxcli software vib list | grep ne1000 ne1000 0.8.4-11vmw.701.0.0.16850804 VMW VMwareCertified 2020-12-16 [root@vm0:~]
Intel-NUC-ne1000_0.8.4-3vmw.670.0.0.8169922-offline_bundle-16654787.zip から VMW_bootbank_ne1000-intelnuc_0.8.4-3vmw.670.0.0.8169922.vib を取り出して、ESXi 上に配置し、インストール:
esxcli software vib install -v /SOMEWHERE/VMW_bootbank_ne1000-intelnuc_0.8.4-3vmw.670.0.0.8169922.vib
2020-12-13: use after free の問題 の結論は、
diff --git a/sys/dev/acpi/dsdt.c b/sys/dev/acpi/dsdt.c index 36c39deb63c..489b689a44c 100644 --- a/sys/dev/acpi/dsdt.c +++ b/sys/dev/acpi/dsdt.c @@ -2740,13 +2740,17 @@ aml_rwfield(struct aml_value *fld, int bpos, int blen, struct aml_value *val, } else if (mode == ACPI_IOREAD) { /* bufferfield:read */ _aml_setvalue(val, AML_OBJTYPE_INTEGER, 0, 0); - aml_bufcpy(&val->v_integer, 0, ref1->v_buffer, - fld->v_field.bitpos, fld->v_field.bitlen); + if (val->length >= aml_bytepos(fld->v_field.bitpos) + + aml_bytelen(fld->v_field.bitlen)) + aml_bufcpy(&val->v_integer, 0, ref1->v_buffer, + fld->v_field.bitpos, fld->v_field.bitlen); } else { /* bufferfield:write */ val = aml_convert(val, AML_OBJTYPE_INTEGER, -1); - aml_bufcpy(ref1->v_buffer, fld->v_field.bitpos, &val->v_integer, - 0, fld->v_field.bitlen); + if (ref1->length >= aml_bytepos(fld->v_field.bitpos) + + aml_bytelen(fld->v_field.bitlen)) + aml_bufcpy(ref1->v_buffer, fld->v_field.bitpos, + &val->v_integer, 0, fld->v_field.bitlen); aml_delref(&val, "wrbuffld"); } aml_unlockfield(NULL, fld);acpibat で、"_BIF" の値を取得しようとするが、その先の AML がバグっていて、 未割り当ての領域に ByteField を定義して読み込んだ後、さらにその値を インデックスとして使って、未割り当ての領域に 0x20 を書き込む。 (VAIO のバグは後日書くつもり)
2020-12-13: これまで acpibat acpitz を無効にして回避してきたが、 上記の diff でピンポイントで回避することで、他の問題も修正されると よいのだか..
2020-12-10: OpenBSD 上で採取した、データリンクタイプ LOOP の pcap を Linux 上で見るための one liner
perl -e '$_=do{local $/;<>};s/^(.{20})./$1l/;print' 0.pcap > 1.pcapLinux の RAW を BSD の RAW に
perl -e '$_=do{local $/;<>};s/^(.{20})./$1\x0e/;print' 0.pcap > 1.pcap2020-12-09: 2021 年の祝日問題 https://github.com/osamutake/japanese-holidays-js/issues/8 Issue は上がった
2020-12-09: use after free のデバッグ を再開 acpitz ではなく acpibat の問題のようだ
2020-12-07: OpenBSD 6.8 amd64 用の chromium-87.0.4280.88 (野良ビルド) おいた 消した
2020-12-04: vaio がクラッシュして 9:15〜9:45 に受信した 7 通のメールを失った
1 from=<owner-tech+M79590=yasuoka=yasuoka.net@openbsd.org> 2 from=<bounces-source-changes-full-owner-yasuoka=yasuoka.net@NetBSD.org> 3 from=<owner-misc+M187293=yasuoka=yasuoka.net@openbsd.org> 4 from=<owner-tech+M79591=yasuoka=yasuoka.net@openbsd.org> 5 from=<bounces-source-changes-full-owner-yasuoka=yasuoka.net@NetBSD.org> 6 from=<bounces-source-changes-full-owner-yasuoka=yasuoka.net@NetBSD.org> 7 from=<bounces-source-changes-full-owner-yasuoka=yasuoka.net@NetBSD.org>
今回はメーリングリストからのメールだったので取り戻せる。 サーバからメールを消す前に fsync するようにした が効果あるだろうか。
2020-11
2020-11-13: Super(Windows) キー + マウススクロールで画面の拡大縮小できるの今気づいた
2020-11-10: https://marc.info/?l=openbsd-ports&m=160494916900934&w=2 anthy 直った。 commit 済み
2020-11-09: panic した
0x54159 - 0x54167 0x54169 - 0x54200 0x54202 - 0x54266 0x20053a - 0x20053a extent_free: start 0x1fff, end 0x1fff panic: extent_free: region not found Stopped at db_enter+0x10: popq %rbp TID PID UID PRFLAGS PFLAGS CPU COMMAND 462648 56805 5063 0x300003 0x4000000 2 chrome 113740 92817 5063 0x100000 0x40 3 xconsole 180965 51434 73 0x100010 0 1 syslogd *496410 39095 0 0x14000 0x200 0K reaper db_enter() at db_enter+0x10 panic(ffffffff81e179fc) at panic+0x12a extent_free(ffff8000005aaa80,1fff,1,10) at extent_free+0x304 uvm_swap_free(2000,1) at uvm_swap_free+0xce uvm_anfree_list(fffffd825f63b030,ffff80002470bb48) at uvm_anfree_list+0xe4 amap_wipeout(fffffd824f99f610) at amap_wipeout+0xe7 uvm_unmap_detach(ffff80002470bbf8,1) at uvm_unmap_detach+0x144 uvm_map_teardown(fffffd81ea9cbaa0) at uvm_map_teardown+0x1c9 uvmspace_free(fffffd81ea9cbaa0) at uvmspace_free+0x5d uvm_exit(ffff8000fffaf0a0) at uvm_exit+0x24 reaper(ffff8000246ff160) at reaper+0x14c end trace frame: 0x0, count: 4 https://www.openbsd.org/ddb.html describes the minimum info required in bug reports. Insufficient info makes it difficult to find and fix bugs. ddb{0}> db_enter() at db_enter+0x10直前の 0x20053a - 0x20053a はなんだろう? 仕込んだデバッグコードだったっけ? dumpsys し忘れて core はなし
2020-11-09: emacs 27.1 になったからか、emacs-anthy が壊れている。
pre-edit で文字化け。
2020-11-07: OpenBSD 6.8 amd64 用の chromium-86.0.4240.185 (野良ビルド) おいた 消した
2020-11-06: ようやく vaio を 6.8 にできた... 時間感覚が.. もう冬なの?
2020-11-06: mailfilter 書いてたのが、おおおそ一年前 か... mailfilter でだいぶメール環境改善した
2020-11-06: 最後に追いかけてた不具合は、一つは単にファイルのパーミッシ ョンの問題で、もう一つは、2 種類のクライアントのうち片方にだけ機能を足 すべきところが混ざってしまって、ぶっ壊れてた。どっちもすぐに問題を見つ けられてもよかった感じもするけど、異様に時間がかかったし難しく感じた.. if の condition に ! xxxx->fugafuga && を足して直ったという記憶が 強烈に残っている。パーミッションが原因の不具合は、普段そんなとこ壊す なんていう不具合は絶対に入らないから、想定から外してた..
2020-11-06: 早速 panic したぞ！
kernel: protection fault trap, code=0 Stopped at amap_lookup+0xb0: movl 0x10(%r10),%edi ddb{2}> amap_lookup(fffffd816bbdb920,1000) at amap_lookup+0xb0 uvm_map_clean(fffffd81c43da000,27018c462000,27018c46f000,4) at uvm_map_clean+0x34a syscall(ffff80003630aba0) at syscall+0x389 Xsyscall() at Xsyscall+0x128 end of kernel end trace frame: 0x7f7ffffc8790, count: -4 ddb{2}>dumpsys 成功したのに savecore し忘れた。けど大丈夫。たぶん再現性高いので。
2020-10
2020-10-26: このサーバを収容してるマシンが異音を発していて、調べたら電 源ファンがほとんど回転しておらず異音を発していた。背面ファンも動いてな かった。amazon で交換部材を発注して、交換。無事完了
- Mini-ITX で使われている電源は「SFX」と呼ばれる規格であることを知った
- 元は 300W のもので 3000 円台からあるようだが、ファンが劇うるさかったら どうしよーとか、安物ですぐこわれるのかも、とか考えて SilverStone の 450W 6,980円のものした。8cm のファンも似たような選び方で 1336 円。 よくわからないから高めのやつ、という、おっさんっぽい買い方なのかもしれない
2020-10-15: 20 年ぐらいまえに書かれた日本の BSD 使いの記事を読むと、 「ports は軟弱だから、手でコンパイルしよう」(意訳) みたいなことが書かれ ていた。記事は、個個人の能力を高めようということを書いていて、当時自分 もそんなものかなと思っていた。けれど、コミュニティでノウハウを共有しよ うと思えば、「同じ package を使って、同じ ports ツリーで直そう」という 発想になるし、当時から、本家の ports メンテナはそういう思いでやってい たはず。しかし日本の BSD コミュニティはそういうことよりも、個人の技術力 を重視する文化だったんじゃないかと思う。(言い方を変えると、ports の本 来の思想とズレた考えが日本で広まっていたのではないかと思う) 日本人は実 は個人主義という話をどっかでもきいた。知の独占が悪いことという考えも希 薄な傾向があると思う
2020-10-11: acm 経由で safari online 使う場合、3 ヵ月アクセスしないと deactivate されちゃうのね... https://learning.acm.org/faq/oreilly-faqs#deactivated acmhelp にメールしてみたが、どれぐらいの時間で解除してくれるのだろう
10/12 はコロンブスの日だからお休みで、結局 10/14 01:04 JST に制限解除したよ、というメールが届いた。
2020-10-06: chrome の chrome://restart は少し前から使い始めているのだが、 本日普通に終了しても、再び起動した時に ctrl-shift-t でタブが復活することを知った。Window が複数あった場合は何回も押せばよい。 自分の環境では chrome 起動しっ放しと調子悪くなるので、 これでリフレッシュしたり、 別件にメモリを使いたいけどブラウザのセッションは継続したい場合に便利。 バッドノウハウかもだけど...
2020-09
2020-09-25: OpenBSD 6.6 amd64 用の chromium-85.0.4183.121 (野良ビルド ) 消した
2020-09-13: 2020 Arctic Vault program のコントリビュータということになっている
いいじゃん。
2020-08
2020-08-27: Microsoft's war on plain text email in open source mew-ja でも このスレッド で、uipc_mbuf2.c みたいなファイル分割はツールが古かった時代の名残りでは? みたいな話があって、ふとそれを思いおこした。
OpenBSD で diff をやりとりする場合には、 patch < ~/Mail/inbox/xxxx できる 必要があると思うけど、メーラの制限で、HTML だけじゃなく、xx 桁で折り返し ちゃったり、quoted printable になっちゃったり base64 になっちゃったりする 人は多い。自分は、かつて tab を適切に表示できない人向けに untabify するくせ がついていて、うっかり diff を untabify して送ってしまい、 怒られたことがあった。
2020-08-21: "Fixed a bug where" の where が、どうして where なのかわからない。 https://english.stackexchange.com/questions/302469/fixed-issue-where-or-that いまいちピンとこない。状況や条件だから where という説明だが、 むしろ a bug が何をもたらしたかで修飾している。 "Fix a bug which caused contracts weren't saved into the database" と言い換えられるわけだし。状況、条件というより、結果。
"原因なのか結果なのか条件なのかわからないけど、とにかく関係のあることを where に続いて並べればよい" という話ならば理解できる
2020-07
2020-07-21: mio の FiberAccess/NF とりあえずルータまでは設定してみた
2020-07-21: IPoE 経由で、ssh が使えない
DSLite の中身の IPv4 でも同様
IPv4 TOS, IPv6 Traffice Class の指定が仇となっているようなので、 以下で回避
match out on vmx0 set tos 0x0 match out on gif0 set tos 0x0
- 当初は proto tcp to port 22 を指定していたが、FTP のデータポートの 通信も該当するっぽくその場合、ポート番号で絞れないので、上記のよう になった
https://ch.nicovideo.jp/tsutsui/blomaga/ar1652866 https://tsutsui.hatenablog.com/entry/ar1652866 有名な問題っぽい
2020-07-21: pf の from urpf-failed は rdomain != 0 に対応していないようだ
さらに
match in to (pppoe0) rtable 0 tag OK pass in tagged OK block from url-failed
だと、block にマッチするが
pass in to (pppoe0) rtable 0 block from url-failed
block にマッチしない、というような現象もような感じ
2020-07-01: 自宅を IPoE 接続に対応すべく mio FiberAccess/NF を申し込んだ
2020-06
2020-06-27: Mew で S/MIME 署名付きのメールを表示しようとすると、 S/MIME verifying... で待たされる現象が発生していた。
これは某社のネットワークでは、インターネットへの 80/tcp や 443/tcp がブロックされているため、S/MIME の証明書の検証で、CRL を取得しようとした際に、その HTTP のアクセスがブロックされ、 タイムアウト待ちになっているようだ
CRL の取得は dirmngr というプログラムで行うので、dirmgr.conf に HTTP プロキシの設定を行えばこの問題は回避できる
echo "http-proxy: proxy:8080" >> ~/.gnupg/dirmngr.conf
2020-06-26: Mew から gnupg が使えなくなる問題を修正 https://marc.info/?l=openbsd-ports&m=159316618816176&w=2
- この問題、手元の mew + emacs では発生せずに ssh 越しの mew + emacs で発生するので、長年の謎で、わりと困っていた
- emacs にも bug report したけど、なかなか更新されないな。https://lists.gnu.org/archive/html/bug-gnu-emacs/2020-06/index.html patch が反転しているので、訂正したいのだけど。
- https://lists.gnu.org/archive/html/bug-gnu-emacs/2020-06/msg01102.html 訂正した
- OpenBSD にも commit 済
2020-06-08: OpenBSD 6.7 amd64 用の chromium 83.0.4103.97 (野良ビルド) 消した
2020-06-04: LKML: Linus Torvalds: Re: clean up kernel_{read,write} & friends v2 自分は 161 桁を tmux で 80 80 に分割して使っている
2020-06-04: delphinusdns で、cvs2gitdump を使っているらしい http://delphinusdns.org/blog/c?article=1588090162
2020-05
2020-05-05: acm 入会。safari online 目当て。 $499/year が acm だと $99/year になるのは...
2020-05-12: x11vnc を使っていると IPC の残骸が大量に残ることがある。 乱暴だけど、一括削除するコマンド:
ipcs | grep ^m | awk '{print $2}' | xargs -n 1 ipcrm -m
2020-04
2020-04-23: OpenBSD 6.6 amd64 用の chromium 81.0.4044.113 (野良ビルド) 消した 6.6 用はこれが最後かな
2020-04-23: https://gist.github.com/yasuoka/0609087b82dda64290b341d02acee196 npppd 関連テスト
2020-04-21: 6.7-beta 化。pkg_add -u はまだ。
2020-04-20: Kenowa という中華メーカーの 13.3" のモニタを amazon で 14,590円 で購入。 1920x1080 って書いてあったけど、実際には 2540x1920 だった。 vaio pro pk は 3840x2160 なので、xrandr --output HDMI-1 --mode 2560x1440 --scale 1.5x1.5 と 1.5 scale しておいて並べると大変良い感じ。 モノは、https://www.aliexpress.com/item/32930704560.html だけど、微妙に MENU とかの表示が違うのはなんなんだろ。 レザーケースは欲しかったけど、もう amazon.com でも売ってない。 ACアダプタは、品切れで急遽適当に作ったのか、ジャック側が変換アダプタで接続するダサい感じだった。USB で給電するので問題ないけど。
2020-04-13: OpenBSD 6.6 amd64 用の chromium 80.0.3987.162 (野良ビルド) (2020-04-23 消した)
2020-04-13: 6.6 on vaio pro pk。大変安定した
9:41AM up 10 days, 22:47, 2 users, load averages: 1.21, 1.92, 1.75
2020-04-10: 思い切って ESXi 6.5 にしてみたら、82578DC は問題なく、 標準ドライバで動いている
[root@vm:~] grep 8086:10f0 /etc/vmware/driver.map.d/e1000e.map [root@vm:~] regtype=linux,bus=pci,id=8086:10f0 0000:0000,driver=e1000e,class=network
2020-04-10: 1TB SSD x 2 の取り付けも完了
2020-04-10: さらに ESXi 7.0 へアップグレードして再起動すると Unsupported CPU となり起動しない。CPU Core i3 550 は 6.5 までしかサポートされないらしい。ということで、本日はここまで。 次に予算がついた時に、マザボ、CPU、メモリを新調して 7.0 化する。
2020-04-10: 最近の chromium なら Skype できるのでは? と思い、試してみたが、チャットは OK だけど、音声はダメだった...
2020-04-10: 自宅の ESXi 環境をじわじわと変更していく。1TB SSD (SANDISK SDSSDH3-1T00-J25) x 2 を発注
2020-04-10: 続いて ESXi 7.0 にアップグレードしたいが、NIC が Intel Corporation 82578DC Gigabit Network Connection (8086:10f0) で、 ドライバがないっぽい。「Intel® Ethernet Adapter Complete Driver Pack」 https://downloadcenter.intel.com/download/22283 に 82578DC のドライバは入ってるっぽいが、README には vmkernel 6.0 とだけ書かれていて、7.0 で使えるのかわからない。 稼働中のマシンで試行錯誤できないので、7.0 化は、M/B、CPU、NIC、RAM を買い換えるタイミングか。
2020-04-08: 解像度の低い外部モニタに出力する場合や、 解像度が低すぎるアプリケーションを使う場合に、スケーリングしたい状況がある。 コマンドラインでは:
env GDK_SCALE=0.5 GDK_DPI_SCALE=0.5 CLUTTER_SCALE=0.5 program
などとすればよく、また xrandr でもモニタごとに scaling の設定ができる
2020-04-07: OpenBSD 6.6 amd64 用の chromium 80.0.3987.162 (野良ビルド) (2020-04-13 消した)
2020-04-07: OpenBSD 6.6 amd64 用の chromium 80.0.3987.162 (野良ビルド) (2020-04-13 消した) Teams で画面共有できる版
2020-04-07: モニタ、Window ごとに DPI を変える方法 https://askubuntu.com/a/555812
2020-04-06: 直した chromium のビルドは今晩にならないと終わらない見込みだが、 それまでの間 Teams 使えないと仕事にならないため、80.3987.163 79 にダウングレードしたところ、cookie などのデータに互換性がないらしく、 ログイン状態がすべてリセットされてしまった... 80 に戻してもダメ。Teams のみ別端末でしのぐほうがマシだった...
2020-04-05: OpenBSD 6.6 amd64 用の chromium 80.0.3987.162 (野良ビルド) 2020-04-07 消した
2020-04-05: chromium 80.0.3987.162 だと LINE や Teams が以下のエラーでタブがクラッシュしてしまう
# Fatal process out of memory: Failed to reserve memory for new V8 Isolate
ktrace で追うとこのエラーの直前に
14229 chrome CALL mmap(0x3b0300000000,0x200000000,0<PROT_NONE>,0x1002<MAP_PRIVATE|MAP_ANON>,-1,0) 14229 chrome RET mmap -1 errno 12 Cannot allocate memory
というエラーが発生している。8GB のメモリ領域を割り当てようとしている。
ソースコード的には https://chromium.googlesource.com/v8/v8.git/+/refs/heads/master/src/init/isolate-allocator.cc#133 のあたり。 https://monorail-prod.appspot.com/p/v8/issues/detail?id=9645 をみると pointer compression が有効な場合に 8GB のメモリを割り当てるということがかかれている。
あらためて OpenBSD の www/chromium のコミットログを見ると、 pointer compression は有効になったり無効になったりして、問題に取り組んだ形跡が見られる。 最終的には、 https://github.com/openbsd/ports/commit/a4a061cdfe8ded0ee3ccf933f50e8c5be4d8b28d に "new RLIMIT_DATA accounting has been committed" となった後に有効になっている。 head では RLIMIT_DATA まわりが修正されたから有効になっているのであって、 私は 6.6 で動かしているので、引き続き無効にしておく必要がある、ということのようだ。 これから 80.0.3987.163 をビルドするので、そこで直す。
2020-04-05: エイプリルフールネタに騙された https://twitter.com/yasuoka_m/status/1246263118168088576
2020-04-04: 自宅の作業スペースまで有線 LAN を敷設
2020-03
2020-03-28: git の tag や commit に GPG の署名をつけられるが、もし時刻 証明がつけられるなら、(例えば遺書とか) 使い途あるじゃんと思ったが、そ こまではできないっぽい https://stackoverflow.com/a/12039018/8542272
2020-03-26: 'Various ACPI events cause kernel to fully load CPU' - MARC やっぱり ACPI events で問題おこるよね。自分はメモリ破壊が起こってる。
2020-03-21: これまで、Google Drive との連携は、 grive2 を用いていたが、本日会社の作業マシンでも同期しようとしたところ、 "This app isn't verified" というエラーとなり設定が行えなかった(*1) (*2)。 エラーの原因などをいろいろと調査してわかったことは、 grive には OAuth2 のクライアント ID や クライアントシークレット ハードコードされていて、そのようなプログラムに Google アカウントの権限を与えるのは大変危険らしい(*3)。 こういう危険を見落として grive2 を使っていたことは、反省すべきである。
で、あらためて他のソフトウェアの探してみると rclone が評判がよく、オープンソースだし、 OpenBSD の ports もある、ということで、こちらを使うことにした。 アプリへの権限付与の問題は、 https://rclone.org/drive/#making-your-own-client-id に書かれている手順で行える。 OAuth consent screen の設定で、"google による verification が必須?" と勘違いしてしまい戸惑ったが、単に Save まで進めば、client id は 発行できるようになる。verification は経ていないので、同意画面の前に、 "This app isn't verified" となるが、"Advanced" から続行することができた
*2: Different OAuth2 client to workaround over quota and google approval issues
*3: https://security.stackexchange.com/a/107372
(訳) アプリケーションにクライアントシークレット bl4ufi89h-9MkFlypcI7R785 が直接埋め込まれている。 このアプリに Google アカウントの権限を与えることは、 クライアント ID とこのシークレットを悪意を持って使うアプリに権限を与えることになる。 さらに言えば、このクライアントシークレットの漏洩により、 通信するサーバの正当性を確認するための防御層を壊すことなる。
2020-03-20: hyperestraier の不具合っぽい動作を見つけてしまった 直せるかなぁ...
2020-03-12: mew の summary mode での "mu" の意味を誤解していた。すべての review mark (*) を取り消すものだと勘違いしていた。o D X を unmark するのか。
2020-03-11: "pf: honor quick on anchor rules" https://marc.info/?t=153860918100012 pf わかってないと意味不かもしれないけど、このスレッドはすごくおもしろい
2020-03-10: 手が滑って yasuoka.net の NS/SOA 以外のすべてのレコードを削除した zone 情報を流してしまった...
2020-03-09: comaddr => serial console の問題 https://marc.info/?l=openbsd-tech&m=158313173511513 は commit した
2020-03-09: コロナで、t2k20 (台湾のハッカソン) も流れてしまいそう...
2020-03-09: "ipmi0: sendcmd fails" https://marc.info/?l=openbsd-tech&m=158312905010821&w=2 は commit した
2020-03-04: 反応してもらえてないなー
- https://marc.info/?l=openbsd-tech&m=158313173511513&w=2
- https://marc.info/?l=openbsd-tech&m=158313065911229&w=2
- https://marc.info/?l=openbsd-tech&m=158312905010821&w=2
- https://marc.info/?l=openbsd-tech&m=158312418109749&w=2
vaio の diff とかもあるから、まだまだたくさんあるんだけど。
2020-02
2020-02-15: dumpsys() が途中で止まる nvme(4) の問題 コミットした
2020-02-15: 完成させてない https://github.com/yasuoka/mailfilter だけどすげー便利だわ。 こういう、設定をプログラムにしちゃったほうが良いパターンって名前があるよねきっと。なんて呼ぶんだろう。
2020-02-03: kevlo さんが使ってる https://0x0.st/ っておもしろい。 ソースコード https://github.com/lachs0r/0x0 NSFW 検出するのか。 NSFW (not safe for work) という言葉も知らなかった
2020-01
2020-01-30: smtpd の脆弱性 の対応完了。 ずっとアップグレードをサボってたので結構大変だった
2020-01-30: Mew で送信失敗したメールが +queue に放置される問題対策で、 X 使ってる手元のホストは、定期的にチェックして +queue に残留があれば、 デスクトップ通知を発火するようにしている。 X 使ってないホストは未対策だったが、以下の ようなスクリプトを .login に仕込んだ (tcsh 使っているので csh script)
if (`find ${HOME}/Mail/queue -name '[1-9]*.mqi'` =~ ?*) then echo "*** You forgot a mail in +queue" enndifこれでそのホストにログイン時に残留があれば警告される
2020-01-28: use after free acpi の 16バイト以下の malloc をフリーしないようにすると、再現性は顕著に低下する。 常に動いているのは acpibat と acpitz の notify なので、この notify を止めてみた。これで再現しなければ、コード的にかなり限定されるので、 なんとかなるだろう。
2020-01-28: uptime 11 時間越えてもまだ panic なし。ビンゴだろうか
2020-01-17: OpenBSD 6.6 errata 017 後、まだ panic はしていないが、2 回ハング
2020-01-17: suspend したら、勝手に起動していて、X の画面真っ黒。 コンソールには切り替わる。外部モニタには出力されたので、外部モニタのモード (ミラーor拡張) を弄っていたら、復活。モニタへの出力が off られてるってこと?
2020-01-16: chromium で chrome cast できることを確認。すげー便利
2020-01-16: OpenBSD 6.6 errata 017 "Execution Unit state was not cleared on context switch with Intel Gen9 graphics hardware." とりあえずあててみる。
2020-01-16: AsahiNet の件、 障害アナウンス 出てた
2020-01-16: package-stable はちゃんと回ってるっぽいので、chromium はそちらを使うことにする。http://ftp.iij.ad.jp/pub/OpenBSD/6.6/packages-stable/amd64/
2020-01-15: AsahiNet 固定 IP アドレス、外への 25/tcp が突然使えなくなり、そして復活した:
Jan 15 11:05:22 mail smtpd[4117]: smtp-out: Connected on session 6f573d1d4a8c8b55 Jan 15 11:13:31 mail smtpd[4117]: smtp-out: Connected on session 6f573d2e1a60053d Jan 15 11:21:15 mail smtpd[4117]: smtp-out: Connected on session 6f573d40486d5392 Jan 15 11:23:31 mail smtpd[4117]: smtp-out: Error on session 6f573d463eb0a5d2: Connection timeout Jan 15 11:23:33 mail smtpd[4117]: smtp-out: Error on session 6f573d47307fb267: Connection timeout Jan 15 11:25:48 mail smtpd[4117]: smtp-out: Error on session 6f573d550cc654ad: Connection timeout Jan 15 11:25:50 mail smtpd[4117]: smtp-out: Error on session 6f573d56c7adc4b9: Connection timeout (snip) Jan 15 15:02:46 mail smtpd[4117]: smtp-out: Error on session 6f5740940788fa1e: Connection timeout Jan 15 15:02:48 mail smtpd[4117]: smtp-out: Error on session 6f5740958bdbdf15: Connection timeout Jan 15 15:05:46 mail smtpd[4117]: smtp-out: Connected on session 6f5740a2f6a8467c Jan 15 15:05:48 mail smtpd[4117]: smtp-out: Connected on session 6f5740a3a2a3bc5a
- サポートに連絡してみた
2020-01-14: メールサーバが 258 日問題 を発症していた。(古いバージョンを使っていることがバレてしまうが...) これに巻き込まれて、同じ relayd の別ホストへの中継も行われなくなっていたようだ
2020-01-09: OpenBSD 6.6 amd64 用の chromium 79.0.3945.88p0 (野良ビルド):strike 2020-04-05 消した
2020-01-01: happy new year