Init · レッスン 3

Upstart の概要

従来の Upstart init システムが、イベント式とジョブのライフサイクル目標をどう結び付けるか学びます。

Upstart は Canonical が開発した、従来のイベント駆動型 init・サービス管理システムです。古い Ubuntu とほかのいくつかのディストリビューションで使われていましたが、現在の Ubuntu は systemd を使います。現代の環境で標準だと思い込まず、Upstart の稼働が確認された古いホストを保守するときに学ぶ仕組みです。

古い Upstart ホストを確認する

PID 1 と稼働中の制御インターフェースを調べます。

$ ps -p 1 -o pid,comm,args=
$ readlink /proc/1/exe
$ initctl version

最後のコマンドが意味のある形で成功するのは、Upstart の制御サービスとクライアントが存在する環境だけです。/usr/share/upstart のようなディレクトリや /etc/init に残るファイルは弱い証拠です。別の init システムへ移行した後も、パッケージや移行時の残骸が残ることがあります。

ホストが実際に Upstart を使っていることを示す最も強い証拠はどれですか？

ジョブとイベント

Upstart の ジョブは、プロセス用コマンドとライフサイクル条件を含む、サービスまたはタスクの定義です。イベントは、任意の環境変数を伴う名前付き通知です。ジョブ設定には、その目標がいつ開始または停止へ変わるかを記述できます。

システムジョブのファイルは通常、.conf という接尾辞を付けて /etc/init/ の下に置きます。次に例を示します。

description "Example worker"
start on runlevel [2345]
stop on runlevel [016]
exec /usr/local/sbin/example-worker

この例は、互換性のための入力としてランレベルイベントを使っています。システムが何をイベントとして発行するかによって、Upstart はファイルシステム、デバイス、ネットワーク、アプリケーション定義のイベントにも反応できます。

Upstart の start on スタンザは何を定義しますか？

イベント駆動の起動

起動中、Upstart はジョブ定義を読み込んでイベントを受信します。一致する start on または stop on の式によってジョブの目標が更新され、ジョブの状態移行から別のイベントが発行されて、ほかの処理が進めるようになる場合があります。互いに独立したジョブは並行して進行できます。

このモデルでは、単一の固定されたグローバルなスクリプト順序を避けられます。一方、イベント名、順序、条件が暗黙的な場合は診断が難しくなります。イベントは既定では永続的なメッセージキューではないため、後から追加したジョブや変更した条件で、過去のすべてのイベントが再送されるとは考えないでください。

ある Upstart ジョブが、別のジョブの開始につながる仕組みはどれですか？

移行と互換性

Systemd は一部の古いサービススクリプトに限定的な互換性を提供できますが、Upstart のジョブ構文をネイティブな systemd ユニットとして実行するわけではありません。移行時はファイル名を機械的に変えるのではなく、ライフサイクル条件、環境、再生成方針、ログ、依存関係、準備完了の意味を明示的に変換してください。

現在の標準的な Ubuntu リリースが使う init システムはどれですか？

レッスン完了