パイプ、フォーク、そしてゾンビ: Unixプロセス管理の理解

モダンなオペレーティングシステムのアーキテクチャは、複数のプロセスを協調させ、データをストリームとしてやり取りできる能力に大きく依存しています。Unix哲学の中心にあるのは「パイプ」という概念で、あるプログラムの出力を別のプログラムの入力として利用できる仕組みです。このモジュラーなアプローチにより、単純で単一目的のツールが、複雑なデータ処理を実現する強力なパイプラインへと変貌します。

これらのパイプがプロセス生成（fork）やプロセス終了とどのように相互作用するかを理解することは、システムプログラマにとって必須です。本稿では、パイプの技術的基礎、SIGPIPE の性質、そして「ゾンビ」状態を回避するためのプロセス階層管理について掘り下げます。

パイプの哲学と進化

パイプの概念は、Doug McIlroy がその技術的実装よりもはるかに前に構想したものです。McIlroy のビジョンは、プログラムを「ホース」のように結合し、データの加工方法が変わるたびに新しいセグメントを差し込めるようにすることでした。このモジュラリティは Unix デザイン哲学の基礎であり、

Technical Note: Some observers have noted that simply piping seq to less does not immediately kill seq, as less remains a reader. The SIGPIPE typically triggers once the user quits less (by pressing q), thereby closing the read end of the pipe and signaling the producer to stop.

このシステム指向のアプローチは、Donald Knuth が提唱したアルゴリズム指向とは対照的です。Knuth は「リテラティブプログラミング」（一部の教材では誤って「literative」と呼ばれる）を開発し、文章とコードを同時に記述して人間の可読性を高める手法を提案しました。Knuth がプログラム内部の論理と構造に焦点を当てたのに対し、McIlroy は複数プログラムのオーケストレーションに注目しました。実際、McIlroy はリテラティブプログラミング環境で膨大なオーバーヘッドが必要だった複雑なテキスト解析タスクも、シェルの数行のパイプで実現できることを示しました。

パイプのメカニズムとSIGPIPEシグナル

パイプが実際にどのように動作するかを理解するために、seq コマンド（数列を出力する）と less コマンド（テキスト閲覧用ページャ）との相互作用を考えてみましょう。

seq 2 100000000 | less を実行すると、seq はパイプへデータを書き込み始めます。しかし、リーダー側（less）がデータの消費を止めるか終了すると、パイプの振る舞いは変化します。ここで重要になるのが SIGPIPE シグナルです。

SIGPIPEの役割

SIGPIPE シグナルは、プロセスがアクティブなリーダーが存在しないパイプへ書き込もうとしたときに送出されます。SIGPIPE を受け取ったプロセスのデフォルト動作は即座に終了することです。これは自動的なリソース管理機能であり、コンシューマがいないのにプロデューサがデータ生成を続ける意味はないからです。

パイプを用いたブロッキング呼び出しの実装

パイプは単なるデータストリーミングだけでなく、同期プリミティブとしても利用できます。たとえば、パイプを使って waitpid() に相当するブロッキング呼び出しを実装できます。

標準的な waitpid(p, &status, 0) 呼び出しでは、親プロセスは子プロセス p が終了するまでブロックします。これと同様の動作をパイプで再現する手順は次のとおりです。

  1. pipe() でパイプを作成する。
  2. fork() で子プロセスを生成する。
  3. 子プロセスは exec() でタスクを実行する。
  4. 親プロセスはパイプの書き込み側（pipfd[1]）を閉じる。
  5. 親プロセスは読み込み側（pipfd[0]）で read() を呼び出す。

子プロセスはパイプのファイルディスクリプタを継承するため、書き込み側は子側で開いたままです。子プロセスが存続している限り、親の read() はブロックし続けます。子プロセスが終了すると、OS が子プロセスのすべてのオープンファイルディスクリプタ（書き込み側も含む）を閉じます。パイプのすべての書き込み側が閉じられると、read() は 0 を返し、親はブロックから解除されます。

プロセス階層とゾンビ状態

Unix 系統のシステムでは、すべてのプロセスが階層構造の中に存在します。このツリーの根元にいるのが init プロセス（PID 1）で、唯一 kill できないプロセスです。

プロセスのライフサイクル

子プロセスが終了すると、システムから完全に消えるわけではありません。代わりに「ゾンビ」状態に移行します。ゾンビプロセスは、親がまだ waitpid() で「待ち受け」ていない終了済みプロセスです。システムはプロセス構造体に終了ステータスを保持し、親が waitpid() で取得できるようにします。

親が waitpid() を呼び出すと、終了ステータスが回収され、プロセス構造体は再利用可能になり、PID が新しいプロセスに再割り当てされます。

ゾンビの増殖とinitプロセス

プログラムが多数の子プロセスを fork() したものの、waitpid() を呼び出さない場合、システムはゾンビで埋め尽くされます。これらは ps コマンドの出力に Z+ と表示されます。ゾンビは CPU やメモリ（プロセステーブルエントリ以外）を消費しませんが、PID を占有します。PID の上限に達すると、新しいプロセスは生成できなくなります。

子プロセスが親より長く生き残ると「孤児」になります。Unix カーネルはこの孤児の親を init プロセス（PID 1）に再割り当てします。init は採用した孤児子プロセスに対して継続的に waitpid() を呼び出すよう設計されており、リソースが確実に解放され、ゾンビが永続的に残ることを防ぎます。

Sources