systemdの基本

ほとんどのユニットファイルの先頭には[Unit]セクションがあります。このセクションを使用して、ユニットファイルのメタデータを定義し、ユニットファイルの他のユニットファイルとの関係を設定します。このセクションは、ユニットファイルの概要を記述していることから通常は先頭に配置されます。

ユニットファイルのタイプごとに固有のディレクティブを記述したセクションです。使用可能なすべてのユニットファイルのタイプについては4項 「ユニットファイルのタイプ」を参照してください。タイプdevice、target、snapshot、およびscopeには、タイプ固有のセクションがないことに注意してください。

これは多くの場合、ユニットファイルの最後のセクションであり、オプションです。このセクションを使用して、ユニットファイルが有効または無効なときのその動作を定義します。ユニットファイルを有効にすると、そのファイルはブート時に自動的に起動します。特定のユニットでは、適切に動作するために他の関連ユニットとの依存関係を持っていることがあります。たとえば、chronyにはディレクティブAfter、Wants、およびBeforeが必要で、これらはすべてchronyが動作するための依存関係です。

サービスやアプリケーションをどのように管理するかを記述します。これには、サービスの開始または停止方法、設定ファイルの再ロード方法(該当する場合)、サービスを自動的に開始する条件、関連するユニットファイルの依存関係または階層情報が含まれます。

このユニットファイルは、systemdによって、D-Busインタフェースから受信した情報から自動的に作成され、外部で作成された一連のシステムプロセスを管理するために使用されます。

パスを使用した有効化で使用するパスを定義します。デフォルトでは、ファイル名のベース名が同じ.serviceユニットファイルが有効になります。inotifyは、ファイルの変更に関する通知を受け取る必要があるプログラムで使用するカーネルAPIです。

systemctl snapshotコマンドによって.snapshotユニットファイルが自動的に作成されます。このコマンドでは、システムの現在の状態を表す一時的なスナップショットが作成されます。システムを変更するとその現在の状態を変更できます。一時的な状態のロールバックにはスナップショットを使用します。

systemdで管理するタイマを定義します。このタイマは、遅延または実行スケジュールを設定した有効化で使用するcronジョブに似ています。このタイマが設定値に達すると、ベース名が同じでファイル拡張子が.serviceであるユニットファイルが起動します。

Linuxのコントロールグループのノードを関連付けます。これにより、スライスに関連付けたプロセスへのリソース割り当てやリソース制限ができます。この名前は、コントロールグループツリーにおける階層を示します。ユニットは、そのタイプに応じてデフォルトでスライスに配置されます。

ブート時または状態の変更時に他のユニットと同期状態にするか、システムを新しい状態にします。他のユニットでは、ターゲットの操作と同期するためにターゲットとの関係を指定します。

ソケットベースの有効化でsystemdが使用するネットワーク、IPCソケット、またはFIFOバッファを記述します。このユニットで定義したソケット上でアクティビティが確認されると起動する.serviceファイルがあります。

ファイルシステムudevまたはsysfsでsystemdによる管理が指示されているデバイスを定義します。すべてのデバイスに.deviceファイルが存在するわけではありません。デバイスの順序指定、マウント、またはアクセスで、このユニットファイルが必要です。

システムのスワップ空間を定義します。ユニットファイルの名前は、この空間のデバイスまたはファイルパスを反映している必要があります。

systemdで管理するシステムのマウントポイントを定義します。このファイルには、スラッシュをダッシュに変更したマウントパスに基づく名前が割り当てられます。/etc/fstabのエントリには、自動的に作成されたユニットを指定できます。

自動的にマウントされるマウントポイントを定義します。参照するマウントポイントに基づくファイル名をファイルに割り当てます。マウントの詳細を定義するには、ベース名が同じ.mountユニットファイルが必要です。

たとえば、ユニットAにWants=unit Bを記述している場合、ユニットAを実行するとユニットBも実行されます。ただし、ユニットBが正常に開始しなくても、正常に実行されているユニットAには何の影響もありません。

ユニットAにRequires=unit Bを記述している場合、両方のユニットが実行されますが、ユニットBが正常に実行されないとユニットAは無効になります。ユニットAのプロセスが正常に実行されているかどうかは関係ありません。

たとえば、ユニットAにBefore=unit Bを記述している場合、両方のユニットを実行すると、ユニットAが正常な実行状態になってからユニットBが実行されます。

ユニットAにAfter=unit Bを記述している場合、両方のユニットを実行すると、ユニットBが正常な実行状態になってからユニットAが実行されます。

デフォルトでブートします。default.targetファイルは、デスクトップワークステーションのgraphical.targetなど、真のターゲットファイルへのシンボリックリンクです。サーバの場合、通常はgraphical.targetです。

システムをシャットダウンして、電源をオフにします。

ベースシステムをプルして、レスキューシェルセッションを開始するターゲットユニット。

グラフィカルではない(コンソール)マルチユーザシステムをセットアップします。

ネットワークサービスを備えたグラフィカルマルチユーザシステムを使用します。

システムをシャットダウンして再起動します。

systemdサービスを開始または有効化する前に、ユニットファイルの構文にエラーがないことを確認します。次に例を示します。

> sudo systemd-analyze verify /etc/systemd/system/my-custom-service.service

このコマンドは、ユニットファイルを分析して、構文エラー、不足しているファイルなどの問題を報告します。サービスを有効にして開始する前に、報告された問題を修正する必要があります。

systemdサービスで問題が発生した場合は、そのサービスのログを確認します。次に例を示します。

> sudo  journalctl -u my-custom-service.service

このコマンドは指定されたサービスのログを表示します。このログにはエラーメッセージや警告などの関連情報が記録されています。これらのログを使用して、サービスの問題を特定して修正できます。

ブートプロセス中にサービスで問題が発生している場合は、systemd-analyze plot commandを使用してブートプロセスを視覚化し、問題を特定できます。次に例を示します。

> sudo systemd-analyze plot > boot-plot.svg

このコマンドでは、ブートプロセスと潜在的な問題のグラフィカル表現が含まれるboot-plot.svgというSVGファイルが作成されます。各サービスの開始時刻と停止時刻も含まれます。このファイルをSVG互換の画像ビューアまたはWebブラウザで開き、ブートプロセスで発生する問題の原因となっているサービスを分析できます。

障害が発生したサービスを確認し、ログ出力を検査するには、次のコマンドを実行します。

> sudo systemctl --state=failed

実行しているサービスの現在の状態を確認するには次のコマンドを実行します。

> sudo systemctl status SERVICE

シャットダウンや再起動に長時間を要する場合は、終了していないサービスがあることが考えられます。systemdは、各サービスの強制終了を試みる前に、その終了を一定時間待機します。多く見られる問題は、保留状態のサービスやシャットダウンの停止です。これを確認するには次のコマンドを使用します。

> sudo systemctl poweroff
  Failed to power off system via logind: There's already a shutdown or sleep operation in progress

> sudo systemctl list-jobs

実行中および待機中のジョブをキャンセルし、再度シャットダウンまたは再起動することができます。

> sudo systemctl cancel

> sudo systemctl stop systemd-suspend.service

実行しているサービスの現在の状態を確認するには次のコマンドを実行します。

> sudo systemctl status SERVICE

設定ファイルや、systemdユニットファイルのスクリプトなど、実行可能ファイルや必須ファイルには絶対パスを使用します。systemdでは、$PATHなどのユーザの環境変数がファイルの検索に使用されません。

systemctl reloadコマンドでサービスを再ロードするときに実行する特定のコマンドを定義するには、[SERVICE]セクションでExecReloadディレクティブを使用します。再起動を伴わずに設定を動的に再ロードできるサービスで、このディレクティブが効果的です。

[Service]
ExecStart=PATH_TO_EXECUTABLE
ExecReload=PATH_TO_RELOAD_SCRIPT

障害が発生した後でサービスを再起動するまでの遅延時間を秒の単位で定義するには、[SERVICE]セクションでRestartSecディレクティブを使用します。リソースを解放するために指定の時間を必要とするサービスや、システムに対する過大な負荷の原因となりかねない急速な再起動ループを防止するサービスで、このディレクティブが効果的です。

[Service]
ExecStart=PATH_TO_EXECUTABLE
Restart=on-failure
RestartSec=5

リモートコンピュータでの緊急モードを無効化できます。このようなコンピュータとして、Google Cloudでホストされている仮想マシンなどがあります。このモードが有効な場合、そのコンピュータはネットワークへの接続をブロックされます。次に例を示します。

> sudo systemctl mask emergency.service

> sudo systemctl mask emergency.target