wslで動かしたdockerは全部閉じても動いていた

Windows10 でも wsl2 は動く。
ファイルシステムがどうなっているのかは調べていないが、lmdb も動いたことだしなかなか動いてくれそうだ。

 

で、最近お仕事で docker のコンテナを動かすことがあり、wsl 上の Ubuntu 20.04 でどうなのか気になっていた。
起動するときはコンソールを立ち上げるが、そのコンソールが閉じたときにどうなっているのだろうか？

 

docker だとわかりにくいと思ったので、 watch でフォアグラウンドではあるが動かし続けた。

う＾－ん？

止めてみよう。

変わらんな。。。

慎重に見ればまた違ったのかもしれないが、タスクマネージャーのレベルでは現れなさそうだ。
dockerコンテナでも同じようなことをしてみたが、ちょっとわからんかった。

 

「詳細」を見てみると、wsl.exe が 2つ、wslhost.exe が複数、 wslservice.exe が 1つ立ち上がっていた。

wslhost.exe は 6つ立ち上がっていたのだが、たぶんここには現れないのではないかな。

もちろん ps で見ると複数立ち上がっているので、動いていないわけではない。

まあ、Windows の動作にとって wsl が動いているというのは考慮すべきではないというか、うちはうち、よそはよそ、というところなのではないかと思っている(個人の感想です)。
Unix/Linux 的な環境で本番運用するのであれば、わざわざ Windows が動いている必要はないのだ。Windows の立ち位置としては開発環境の提供くらいなものだろう。

 

なので Windows 側から wsl で動いているプロセスが見えないのは、そんなものだろうと思っている。
ただ・・・あのペンギンはなんとかならなかったのだろうか。

怖いよ。

nvs autoとcdするスクリプトは相性が悪そうだ

node.js の切替に nvs を使っている。

https://github.com/jasongin/nvs

nvs auto on しておくと、.node-version に使用したい node.js のバージョンが書いてあれば cd したときに自動で切り替わる。

 

私は Ubuntu を使っているのだが、デフォルトの node.js は v12.22.9 になっていた。
よく使うのは v16系なのだが、グローバルでインストールするようなコマンドも意識的に使っていないのでデフォルトのままにしている。
何か実装したり動かしたりするときに nvs use で指定しているのだが、たまに忘れてデフォルトのまま使ってしまい、なんか動きがおかしいなぁ、というところで気付いたりする。

そういうのを避けるために nvs auto on と .node-version は便利そうなのだ。

---

ただ、私の環境だと .bashrc で nvs auto on しているとなんか変だったのだ。
勝手に知らないディレクトリが作成されたり、エラーで mkdir の使い方が間違っていると出てきたり。

そして先ほど、.bashrc がこうなっているのに気付いた。

• NVS_HOME などの設定
• nvs auto on
• GOPATH を設定するスクリプトの実行

よろしくなかったのは最後の GOPATH を設定するスクリプト。
ここ最近 GOPATH が必要なプロジェクトの作業ばかりしていたので GOPATH を設定するスクリプトを作って source コマンドで読み込ませていた。

#!/bin/bash

export GOPATH=$(cd $(dirname $BASH_SOURCE); pwd)
export PATH=$GOPATH/bin:$PATH
mkdir -p $GOPATH/src $GOPATH/pkg $GOPATH/bin

GOPATH をあちこち置いていたので、このスクリプトファイルを置いて読み込めばそのディレクトリを GOPATH になるようにしていた。

スクリプト中で cd しているところがあるのだが、これによって nvs auto on が作動してしまうようなのだ。
cd だから作動するのは当たり前なのだが、 .bashrc でこのスクリプトを実行することと nvs auto on の組み合わせによってターミナルを新しく開いたとき、特に vscode で開いたときの挙動がよくなかったようだ。

 

まあ、これは .bashrc の中でこういうスクリプトを走らせる方が良くないな。
スクリプトの場所＝GOPATH の場所なので、直接そう書けば良いだけなのだ。あるいは nvs auto on の前に呼び出すようにするかだ。

[wsl2] lmdbは動くようになった

4年ほど前、こういう記事を書いていた。

hiro99ma blog: [lmdb][win10]Windows10 1803でWSLのファイル書込みがうまく動いてない？(2018/05/05)
https://hiro99ma.blogspot.com/2018/05/lmdbwin10windows10-1803wsl20180505.html

あれから、WSL2 といってよいのかな？ 正式版になったそうだ。

ASCII.jp： Microsoftストア版WSLが正式版になり、Windows 10でも動作可能に (1/2)
https://ascii.jp/elem/000/004/114/4114859/

Windows10 Pro にインストールして使ってみた。

Ubuntu 20.04 は今回新規だが、WSL についてはUbuntu on Windows の時代から同じ PC を使っているので、まっさらな状態から試すわけではない。
・・・この PC ももう6年も使ってるんだな・・・。

 

gist に作っていたサンプルコードを動かした。

$ ./tst
test1(): OK
test2(): OK
  key(5)=test1, data(5)=TEST1
  

エラーになってないということは大丈夫になったのかな？
ファイルアクセスが遅いとかで見直しが行われるようなことをどこかで読んだ気がする。

 

VirtualBox などではなく WSL が使えると、ストレージにあらかじめ確保されるサイズがなくなると思うので、あまり空き容量がない私としてはとても助かるのだ。
いや、そうだろうか？

WSL 2 仮想ハード ディスクのサイズを拡張する | Microsoft Learn
https://learn.microsoft.com/ja-jp/windows/wsl/vhd-size

確保するやん。
探すと、確かに ext4.vhdx というファイルがある。

df で見ると 2GB に近いのは /dev/sdc だろうか。

/dev/sdc       1007G  1.7G  955G   1% /

にしても、この PC は 1007GBもないし、よくわからん。

[vbox] VirtualBox が急に動かなくなる

Windows11 で VirtualBox v7.0.4 + Ubuntu 22.04 を動かしているのだが、なんか急に操作を受け付けなくなることに気付いた。
ホスト側も重たくなってしまっている。

こちらの人はゲスト OS で Windows10 を動かしているようだが、こちらと同じような感じだ。

https://forums.virtualbox.org/viewtopic.php?f=6&t=107712

VBox.log を見るとこんなのが出ていて応答しなくなったようなのだ。

VMMDev: vmmDevHeartbeatFlatlinedTimer: Guest seems to be unresponsive. Last heartbeat received 4 seconds ago

あきらめて v6 にダウングレードした。
まあ、最初は仕方ないよねー

 

2022年12月3日 20:28追記

と思っていたのだが、ダウングレードしても応答しなくなるようになってしまった。
もしかしたら、いまやっている docker buildx build でやっている作業が原因なのか？？

お仕事で docker buildx build する作業をやっているのだが、VirtualBox でやるのは初めてなのでこれが原因かどうかを判断できない。ありがちだが、ダウングレードしても前のファイルか何かが残っていて変になってしまったという可能性もありそうだ。アンインストールって、いろいろな可能性を考えてしまってファイルを残しがちになるので難しいよね。

 

・・・docker の線は消えた。
ゲストOS を立ち上げて vscode を立ち上げて放置していただけだが固まってしまった。
方式が違う VM の重ね合わせになるからかも、なんて考えていたが違ったようだ。

vscode が原因と言うことはないよな・・・？
ただ最近は direnv hook とか使ったり他にも設定し直したりしたので、vscode が直接ではないにしてもなくはないのか。
あとは、長い時間放置した後しか見ていないのでスリープみたいな電源制御もちょっと気になる。

わかるのは VM の CPU負荷が高いということだけで、本当にゲストOS 側でプロセスが立ち上がって非常に重たくなっているだけかもしれないのだ。

 

2022年12月4日 21:17追記

まだ現象が発生する。

いま疑っているのは kernel だ。
私の環境だと最新は GNU/Linux 5.15.0-56-generic x86_64 なのだが、インストールされている1つ前の GNU/Linux 5.15.0-53-generic x86_64 だと発生しない気がするのだ。

 

ブートローダで切り替えるのが面倒なのでデフォルトを 5.15.0-53 にしたかったのだが、どうにもうまくいかない。。。
/boot/grub/grub.cfg が最終的には使われているようだが、/etc/default/grub を変更して update-grub してもうまくいかんので、あきらめて apt remove/purge で削除した。

これで改善すると良いのだが。

 

2022年12月4日 22:24追記

あれから1時間が経過した。
未だに止まる気配がないので、これは成功したんじゃなかろうか。

りゆうはよくわからないが、VirtualBox と Linux 5.15.0-56 が相性が悪いとか、VBox Additions をやったことで相性が悪くなるとか、そんなことかもしれん。

む、ということは VirtualBox 7 にしたこと自体は影響がなかったのか。
元に戻そう。

 

2022年12月4日 23:41追記

VirtualBox 7 に戻して1時間が経過した。
未だに止まる気配がないので、やはり VirtualBox のバージョンには関係が無かったのか。
すまん、疑って。