プロセスの大親分

自分のweb制作知識は基本的に独学で、その都度必要になった知識のみを仕入れるスタンスでやってきました。
一口にweb制作といってもその範囲はめちゃくちゃ広範囲にわたっており、
自分が知る限りweb制作に必要な技術知識全部を網羅した本は存在しません。
そもそもプロの現場でもweb制作は扱う技術スタックもプロジェクトごとに異なる上、
専門ごとに分掌するのが当たり前であり、１人でwebサイトを全部作る方がレアなケースです。
一方、趣味でやっている場合は基本的に１人で全部作らざるを得ないので、横断的に知識を仕入れる必要があります。
そのハードルもAIによってずいぶん下がりましたが、
自分もいまだにおそらく業界の常識だろうに知らなかった概念と出会うことがたまにあります。

先日出会った「tini」もそのひとつです。
tiniとは、Dockerのコンテナに一番最初に起動するプロセスとして起動するように仕込んでおく
ごく小さなプロセス管理ソフトのことで、初期化を意味するinitを逆さから読んでいます。
通常、Linuxは起動すると最初のプロセス（＝PID 1）としてsystemd（システムデーモン）が起動しますが、
これを代替するものという位置付けとしてtiniは存在します
（systemdはわりと近年開発されたもので、かつてはinitというプロセスだったらしい）。

systemdはLinuxの根幹とも言うべきソフトで、OSが起動したら自動起動するソフトを設定するなどの機能を持っています。
LinuxではPID 1のプロセスは全プロセスの大親分のような特殊な役割を自動付与される仕組みになっていて、
ブートシグナルを受け取って最初に起動するsystemdはその役割も担っています。
たとえば他のプロセスが動いていて、そのプロセスの下で子プロセスが動いているとします。
ここでもしその親プロセスが死んだら子プロセスは行き場を失ってしまうわけですが、
PID 1であるsystemdはそうした行き場を失ったプロセスの親プロセスになります。

しかしsystemdそれ自体はLinuxの根幹を担うだけあってそれなりに重いソフトです。
これをDockerコンテナそれぞれに搭載していたらファイルサイズを無駄に食ってしまうことになり、
またコンテナ自体も軽量性をいくらか失うことになります。
Dockerは基本的にカーネルを基盤OSに依存して、差分だけコンテナ内に実装することで軽量化を実現しているため、
systemdをデフォルトで入れるのはその設計思想と相反するわけですね。
もちろんユーザーが自由に入れる分には構わないわけですが。

DockerコンテナでPID 1のプロセスを意図的に指定しない場合、
通常はそのコンテナで主に使用するプログラム（nodeなど）がPID 1になり、
これらがゾンビプロセスの親になってしまいます（あんまりないケースだと思いますが）。
また、Dockerではコンテナの起動・終了シグナルはPID 1のプロセスに飛ばしているので、
nodeなどアプリの動作を司るプロセスがPID 1だと応答に時間がかかるという問題も出てきます
（終了シグナルを正常に受け取れないので、毎回強制終了することになるらしい）。
これらを解決するために、PID 1の椅子に座ってもらうためだけに用意するのがtiniというわけです。

今回はたまたまDockerについて調べていたらこれにたどり着いたのですが、
思い返せばいま運用しているVPSではたまにゾンビプロセスが残っているのを昔から確認していて、
発生要因が分からなかったのでずっと放置していました。
それも今回、行き場を失った子プロセスがあることやコンテナ内はそれを引き受けるソフトが用意されていないことなど、
いろいろ分かってスッキリしたという感じです。
また、おかげでLinuxへの興味が一時的に高まりました。
web技術全体を網羅する本は存在しませんが、
Linuxのコマンドリファレンスなら売っているのでそういうのを買ってパラパラめくってみるのも面白そうだし、
まだ見ぬ常識的なコマンドもたくさんありそうだなと思った次第です。