……に遭遇した。でかいnode_modulesを.dockerignoreもせずにいると、"=> transferring context: " が返ってこなくなるイメージ。こうなるとビルドをキャンセルしてもdockerの操作にまったく反応がなくなり、Factory Resetするしかなくなってしまう。これは困った（ちなみにその後の調査があたってれば、ホストマシンの再起動でもいいはず）。
結論
裏側のLima VMの net.core.rmem_max あたりを大きめにとってあげるとよさそう。~/Library/Application Support/rancher-desktop/lima/0/lima.yaml の provision: に以下のようにひと項目足す。
数字は適当！
--- ~/Library/Application Support/rancher-desktop/lima/0/lima.yaml.bak +++ ~/Library/Application Support/rancher-desktop/lima/0/lima.yaml @@ -153,6 +153,10 @@ mount bpffs -t bpf /sys/fs/bpf mount --make-shared /sys/fs/bpf mount --make-shared /sys/fs/cgroup + - mode: system + script: | + sudo sysctl -w net.core.wmem_max=12582912 + sudo sysctl -w net.core.rmem_max=12582912 portForwards: - guestPortRange: - 1
調査
調査の過程もおもしろかったので残しておく。
ログのありかは設定画面からわかったので、tail -F ~/Library/Logs/rancher-desktop/* しつつ状況を再現してみると、"lima write unixgram -\u003e: write: no buffer space available" という怪しいメッセージを吐いてから行動不能になっている模様。こうなると rdctl shell もできなくなってしまう。
どこかしらでUnixドメインソケットによる通信が行われているらしいが、調べてみたところ no buffer space available になるときはどうも net.core.wmem_max とか net.core.rmem_max のチューニングが効きそう。おそらくlimaのVM側の設定だとあたりをつけたが、そもそもRancher Desktopの裏側で動いてるVMの設定はどこにあるんだ。
psしてみると limactl.ventura hostagent 0 というプロセスが動いてるので ps eww <PID> してLIMA_HOMEが ~/Library/Application Support/rancher-desktop/lima になっていることがわかった。なので設定の本体は上記のYAMLファイル。
このYAMLファイルを見てみるとこういう設定があって、ホストとゲストのUNIXソケットをポートフォワードしてるのだとわかる。
portForwards: - guestSocket: /var/run/docker.sock hostSocket: /Users/motemen/.rd/docker.sock
え、ソケットのポートフォワードってどうやるの、と調べると sshのポートフォワードを使っていた。sshがUNIXソケットのフォワードもできるのは知らなかった。limaのポートフォワードがsshで実現されていることを知ったので、Rancher DesktopがUDPのポートフォワードに対応してないのも理由を理解できた。今回sshの内部までは追わなかったけど、ここでsshが双方のソケットの調停をうまくできてないってことなんだろうか〜。気になったけど、いったん調査はここまでとした。
ちなみにこの記事を書くため状況を作り直してみたのだけどうまく再現させられませんでした……。
