本 日 の h o g e

■ [メモ][JS] octokit.js をブラウザから使える形にバンドルする

$ tar zxf octokit.js-3.1.0.tar.gz
$ cd octokit.js-3.1.0
$ npm install .
$ ./node_modules/.bin/esbuild --bundle --minify --target=es2020 \
    --platform=browser --format=esm \
    --outfile="$(basename ${PWD/.js}.min.js)" ./src/index.ts 

$ ls -l octokit-3.1.0.min.js 
-rw-r--r-- 1 atzm users 194750 Aug 29 11:23 octokit-3.1.0.min.js

これがやりたいだけでめっちゃ調べる羽目になって超時間かかったんだけど，フロントエンド人にはこんなん常識でドキュメントなんか不要ってことなんですかね．

■ [メモ][JS] pdf.js をブラウザから使える形にバンドルする

$ tar zxf pdf.js-3.10.111.tar.gz 
$ cd pdf.js-3.10.111
$ npm install .
$ npm install gulp-cli
$ ./node_modules/.bin/gulp --no-color dist
$ ls -l build/dist/build/pdf{,.worker}.min.js
-rw-r--r-- 1 atzm users  315473 Aug 29 16:34 build/dist/build/pdf.min.js
-rw-r--r-- 1 atzm users 1081229 Aug 29 16:34 build/dist/build/pdf.worker.min.js

基本的には README に書いてある通りなのだけれど，gulp-cli をインストールしなくても .bin/gulp が存在するので変にはまってしまった... (gulp-cli をインストールしないと，ぱっと見ではこれが必要とは分からないメッセージと共にエラー終了する)

■ [Gentoo][小ネタ] systemd な Gentoo で kdump

最近どうも自宅デスクトップ PC の調子が悪く，たまに (たぶん) kernel がクラッシュして止まってしまうことがある．使ってない時に止まってることもあるし，使ってる時に止まることもある． ほぼ X を起動しているので trace が見えず，何が原因なのかよく分からないなあ，などと悠長に思っていたのだけれど，どうも頻度が上がってきたような気がするので，重い腰を上げて，まずは原因を探れるように環境を整えることにした．

とりあえずは trace だけ見えればいいから netconsole でログだけどっかに飛ばすか，などと思ったのだけれど，よく考えたら自宅に常時稼働な syslog サーバなんかなかったので，これは断念．

PC 1台で完結するために選択肢に上がるのが kdump になる． 予め専用に確保しておいたメモリ領域に dump-capture kernel イメージをロードしておき，クラッシュ時にこれを実行する．その際クラッシュした kernel のメモリイメージが /proc/vmcore として見える状態になるので，これを保全した後で安全に reboot すれば良い，というもの．

この dump-capture kernel はなるべく小さい方が望ましいのだけれど，今回は面倒くさいので普段使っている kernel をそのまま使うことにする． Gentoo で single kernel で kdump するには，基本的には Kernel Crash Dumps (Gentoo Wiki) に従って環境を整えれば良いのだけれど，このドキュメントは少し古めの kernel について書かれているのと，OpenRC 用に書かれているので，そこをちょっとだけ工夫する． ちなみにこのドキュメントでは crashkernel=64M となっているが，今回の環境には小さすぎるようなので 512M にしておいた (これが小さいと，dump-capture kernel 上で動く systemd-udevd 等の daemon が OOM で死んだりしてまともに動かなかった)．

まず kernel のコンフィグ． CONFIG_DEBUG_INFO=y とするのは良いのだけれど，最近の kernel ではそれに加えて DWARF のバージョンを選択することになっているようなので， "Rely on the toolchain's implicit default DWARF version" (CONFIG_DEBUG_INFO_DWARF_TOOLCHAIN_DEFAULT=y) とする．

次いで OpenRC の部分を systemd 化する． runscript で行われていることを systemd.service(5) で代替すれば良いので，下記のような service unit を適当に作って enable する．

$ cat /etc/systemd/system/kdump-load.service
[Unit]
Description=Load the second kernel for kdump
After=boot.mount

[Service]
Type=oneshot
ExecStart=/bin/bash -x -c '. <(sed -e "s/ /\\n/g" /proc/cmdline | grep =); kexec -p /boot$${BOOT_IMAGE} --append="root=$${root} single irqpoll maxcpus=1 reset_devices"'

[Install]
WantedBy=multi-user.target

普段使いの kernel で dump-capture kernel をロードしておく必要があるので，multi-user.target に突っ込んでおく． なおここで /boot から kernel のイメージを読み込む必要があるので，/boot パーティションが分かれている場合は注意．

次に，実際にクラッシュした時に動き出すことを想定した service unit を用意する．

$ cat /etc/systemd/system/kdump-save.service
[Unit]
Description=Save the vmcore when the kernel crashes
ConditionFileNotEmpty=/proc/vmcore

[Service]
Type=oneshot
ExecStart=/bin/bash -x -c 'd="$$(date +%%Y%%m%%d-%%H%%M%%S)"; cp --sparse=always /proc/vmcore "/var/crash/vmcore.$${d}" && reboot'

[Install]
WantedBy=rescue.target

単に /proc/vmcore を保全して reboot するだけ． /var/crash ディレクトリは予め作っておくこと． dump-capture kernel は single mode で起動するように指定しているので，rescue.target に突っ込んでいる． システムによっては emergency.target を利用しても良いかも知れない (この場合 crashkernel= のサイズが小さくても大丈夫かも)． rescue.target や emergency.target 等の systemd ターゲットについては systemd.special(7) を参照のこと．

ここまで出来たら後はテスト． Kernel Crash Dumps (Gentoo Wiki) にも書かれている通り /proc/sysrq-trigger に "c" を書き込むとシステムがクラッシュするので，sync(1) した後で実行してみよう． クラッシュした後すぐに dump-capture kernel が起動し，kdump-save.service が動いて /var/crash 以下に vmcore が保全されて reboot が行われたら成功． ちなみに vmcore ファイルは搭載物理メモリ量と同じサイズなのでかなり大きい．保全には結構時間がかかる．

ここまでで vmcore ファイルを保全することはできたけれど，では実際にここから「何が起きていたのか」を知るにはどうすれば良いか． vmcore の解析といえば言わずもがな crash コマンド． Gentoo にも dev-util/crash としてパッケージが存在するのだけれど，なぜか ~ になっているので，accept_keywords に追加する等してから emerge する． このコマンドを使えば gdb ベースのデバッガが起動するので，あとは log とか bt とか打てば trace を見ることができる．

# crash /usr/src/linux/vmlinux /var/crash/vmcore.20230818-171346

crash 8.0.3
Copyright (C) 2002-2022  Red Hat, Inc.
Copyright (C) 2004, 2005, 2006, 2010  IBM Corporation
Copyright (C) 1999-2006  Hewlett-Packard Co
Copyright (C) 2005, 2006, 2011, 2012  Fujitsu Limited
Copyright (C) 2006, 2007  VA Linux Systems Japan K.K.
Copyright (C) 2005, 2011, 2020-2022  NEC Corporation
Copyright (C) 1999, 2002, 2007  Silicon Graphics, Inc.
Copyright (C) 1999, 2000, 2001, 2002  Mission Critical Linux, Inc.
Copyright (C) 2015, 2021  VMware, Inc.
This program is free software, covered by the GNU General Public License,
and you are welcome to change it and/or distribute copies of it under
certain conditions.  Enter "help copying" to see the conditions.
This program has absolutely no warranty.  Enter "help warranty" for details.

GNU gdb (GDB) 10.2
Copyright (C) 2021 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-pc-linux-gnu".
Type "show configuration" for configuration details.
Find the GDB manual and other documentation resources online at:
    <http://www.gnu.org/software/gdb/documentation/>.

For help, type "help".
Type "apropos word" to search for commands related to "word"...

      KERNEL: /usr/src/linux/vmlinux  [TAINTED]
    DUMPFILE: /var/crash/vmcore.20230818-171346
        CPUS: 8
        DATE: Fri Aug 18 17:13:34 JST 2023
      UPTIME: 00:01:16
LOAD AVERAGE: 0.28, 0.13, 0.05
       TASKS: 180
    NODENAME: hostname
     RELEASE: 6.1.41-gentoo
     VERSION: #4 SMP PREEMPT_DYNAMIC Fri Aug 18 15:57:01 JST 2023
     MACHINE: x86_64  (3400 Mhz)
      MEMORY: 31.9 GB
       PANIC: "Kernel panic - not syncing: sysrq triggered crash"
         PID: 550
     COMMAND: "bash"
        TASK: ffff8881026bc000  [THREAD_INFO: ffff8881026bc000]
         CPU: 6
       STATE: TASK_RUNNING (PANIC)

crash> bt
PID: 550      TASK: ffff8881026bc000  CPU: 6    COMMAND: "bash"
 #0 [ffffc90000b83c80] machine_kexec at ffffffff810dbbcc
 #1 [ffffc90000b83cd0] __crash_kexec at ffffffff8126a615
 #2 [ffffc90000b83d90] panic at ffffffff823d8995
 #3 [ffffc90000b83e10] sysrq_handle_crash at ffffffff819a6451
 #4 [ffffc90000b83e18] __handle_sysrq.cold at ffffffff82405783
 #5 [ffffc90000b83e48] write_sysrq_trigger at ffffffff819a6eff
 #6 [ffffc90000b83e58] proc_reg_write at ffffffff8147dc00
 #7 [ffffc90000b83e70] vfs_write at ffffffff813f36a0
 #8 [ffffc90000b83f00] ksys_write at ffffffff813f3c6e
 #9 [ffffc90000b83f38] do_syscall_64 at ffffffff82469cea
#10 [ffffc90000b83f50] entry_SYSCALL_64_after_hwframe at ffffffff8260009b
    RIP: 00007f836d5b8b50  RSP: 00007fff8375c3a8  RFLAGS: 00000202
    RAX: ffffffffffffffda  RBX: 0000000000000001  RCX: 00007f836d5b8b50
    RDX: 0000000000000001  RSI: 000055f0fe7bed70  RDI: 0000000000000001
    RBP: 00007f836d68f780   R8: 0000000000000007   R9: 000055f0fe8b8200
    R10: 0000000000000000  R11: 0000000000000202  R12: 0000000000000001
    R13: 000055f0fe7bed70  R14: 0000000000000a68  R15: 0000000000000001
    ORIG_RAX: 0000000000000001  CS: 0033  SS: 002b

■ [小ネタ] oneshot firefox

何だかよく分からんけどいつの頃からか firefox のプライベートウィンドウを開くと firefox 全体がハングするようになってしまい，しかし今ひとつ原因も不明なので，もう一時的に別プロファイルを作って新しいプロセスを起動することにした．

$ cat ${HOME}/.config/systemd/user/firefox-oneshot-0@.service
[Unit]
Description=oneshot firefox (%i) for display :%j

[Service]
Type=simple
Environment=DISPLAY=:%j
ExecStartPre=/usr/bin/install -d -D -m 0700 -o %u -g %g %T/%p-%i
ExecStopPost=/bin/rm -rf %T/%p-%i
ExecStart=/usr/bin/firefox -no-remote -profile %T/%p-%i

こんなのを作っておいて，

$ systemctl --user start firefox-oneshot-${DISPLAY#:}@$(uuidgen).service

こんな風に起動．

他に必要な環境変数は適宜 Environment= 等を追加のこと．

■ [Py][小ネタ] llesync 再び

数年前に趣味で書いたもの だが，先日新調した PC の上で何となく動かしてみたら思ったより速かったので，結果を README に載せておいた． 何だろうね．以前の結果は Disk I/O で律速してたっぽいから，SSD になったお陰で恩恵を受けられるようにでもなったのかな． あるいは単に kernel が高速化されたか． 調べてないので分からんけど．

まあいずれにせよ単純にコピーする場合において cp には勝てない．っょぃ．

■ [Linux][小ネタ] netplan と systemd-networkd と macvlan とわたし

現状の netplan (0.97) では直接 macvlan インタフェースを作れないらしい．しょうがないので直接 networkd の設定を書いて作ることを考える．

下記のようなインタフェースがあったとして，

# cat /etc/netplan/02-netdev.yaml
network:
  version: 2
  renderer: networkd
  ethernets:
    ens3:
      dhcp4: no
    ens4:
      dhcp4: no
    ens5:
      dhcp4: no

ens5 から macvlan インタフェース vmac0 を生やしてみる． networkd の設定はこんな感じになる．

# cat /etc/systemd/network/00-ens5.network
[Match]
Name=ens5

[Network]
MACVLAN=vmac0
LinkLocalAddressing=no

# cat /etc/systemd/network/90-vmac0.netdev
[NetDev]
Name=vmac0
Kind=macvlan
MACAddress=00:00:00:00:00:01

[MACVLAN]
Mode=private

# cat /etc/systemd/network/90-vmac0.network
[Match]
Name=vmac0

[Network]
LinkLocalAddressing=no

上記はうまくいく例で，下記のように，意図通りにインタフェースが生成される．

# ip -d link show dev vmac0
6: vmac0@ens5: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen 1000
    link/ether 00:00:00:00:00:01 brd ff:ff:ff:ff:ff:ff promiscuity 0 
    macvlan mode private addrgenmode eui64 numtxqueues 1 numrxqueues 1 gso_max_size 65536 gso_max_segs 65535 

さてここからがハマりどころの話．

netplan はその設定情報を元に /run/systemd/network/10-netplan-<インタフェース名>.network というファイルを生成するようだ．上記の例では ens5 が netplan の設定に書かれているため，下記のようなファイルが生成される．

# cat /run/systemd/network/10-netplan-ens5.network
[Match]
Name=ens5

[Network]
LinkLocalAddressing=ipv6

勘の良い諸兄はもうお分かりだろう．上記「うまくいく例」がうまくいくのは，ens5 の networkd 設定を 00-ens5.network という名前にして，netplan が書き出すものより優先的に使用されるようにしたからである． これを例えば 90-ens5.network などと netplan が書き出すものより弱いファイル名にすると，意図通りにインタフェースが生成されず，涙で枕を濡らすことになってしまうことだろう．

もちろん macvlan の元インタフェース (上記例では ens5) については netplan の設定に書かない，という選択もある． しかしいずれにしても設定が分散することになるので，全国津々浦々の macvlan ファンにとって現状の netplan が嬉しくないことに変わりはないだろう．netplan 先生の次回作に期待である．