initctl は稼働中の Upstart init デーモンと通信します。関連する PID 名前空間で実際に Upstart が動いていることを確認してから使ってください。現在の systemd ホストでは、代わりに systemd のネイティブツールを使います。
Init · レッスン 4
Upstart ジョブ
Upstart の稼働が確認された古いシステムで、`initctl` を使ってジョブを確認、制御する方法を学びます。
ジョブの状態を一覧表示して読む
既知のジョブとインスタンスを一覧表示します。
$ initctl list
1つのジョブを調べます。
$ initctl status networking
networking start/running
Upstart は start や stop などの 目標と、running や waiting などの現在の 状態を両方報告します。stop/waiting はジョブが実行中ではなく、開始条件または手動の要求を待っていることを意味し、必ずしもエラーではありません。
Upstart の状態出力で、stop/waiting は通常何を意味しますか？
ジョブを開始、停止する
依存関係と影響を確認した後、次を実行します。
$ sudo initctl start JOB_NAME
$ sudo initctl stop JOB_NAME
ジョブは、環境変数をキーにした複数のインスタンスを定義できます。その場合は、設定が要求する変数を正確に指定し、インスタンスの照会や停止でも一貫して含めます。ネットワーク、ストレージ、認証、リモートアクセスのジョブを操作するとセッションが切れる場合があるため、コンソールから復旧できる手段を確保してください。
ジョブ peanuts の手動開始を要求するコマンドはどれですか？
再起動と設定変更
実行中のジョブを再起動するには、次のように要求します。
$ sudo initctl restart peanuts
Upstart の restart は、ジョブファイルを編集した後の新たな stop、start と常に同じではありません。実行中のジョブでは既存の設定が引き続き基準になる場合があります。変更した .conf を検証し、インストール済みバージョンに合う方法で Upstart に設定を再読み込みさせ、新しい設定を反映する必要があるときは文書化された停止・開始手順に従ってください。
再起動では中断が発生し、サービスが復旧しない可能性もあります。操作後に実際のエンドポイントとログを確認してください。
実行中の Upstart ジョブ peanuts の再起動を要求するコマンドはどれですか？
ジョブ設定を検証する
変更したジョブファイルをインストールする前に、古いディストリビューションが提供する検証ツール（一般には init-checkconf）を使い、読み込まれるスクリプト、環境、ユーザーとグループの設定、再生成方針、イベント式を確認します。その後、バージョンに適した initctl reload-configuration の手順で定義を再読み込みしてください。
構文検証だけでは、パスが存在すること、認証情報に実行権限があること、イベントが到着すること、プロセスが準備完了になることまでは証明できません。復旧できる環境でテストしてください。
ジョブの構文検証では証明できないことはどれですか？
イベントを慎重に発行する
Upstart では名前付きイベントを発行できます。
$ sudo initctl emit EVENT_NAME
開始または停止の式が一致するすべてのジョブが反応できます。イベントは1つのジョブ宛てではなく、さらに別のイベントを通じて影響が連鎖する場合もあります。カスタムイベントやシステムイベントを発行する前に、一致する設定をすべて調べてください。本番ホストで中核的な起動イベントを不用意に再送してはいけません。
initctl emit EVENT_NAME を実行すると、何が起こり得ますか？
レッスン完了
Upstart ジョブ を完了しました
状態とイベントの影響範囲を明示して、Upstart ジョブを操作できるようになりました。
initctlの出力で、目標と状態を分けて読む。影響を確認してから、正確なジョブインスタンスを開始、停止する。
再起動と、変更したジョブ設定の反映を別の問題として扱う。
構文を検証した後、実行時の準備完了までテストする。
イベントを発行する前に、一致するすべての条件を調べる。