「設定 - Systemdサービスユニット」の版間の差分

← 古い編集

ビジュアルウィキテキスト

@@ 85行目: / 85行目: @@
 == ユニットファイルの構造 ==
 ユニットファイルは、3つのセクションで構成される。<br>
+* [Unit]セクション
+*: 依存関係や順次関係等、依存しない設定を記述する。
+* [Install]セクション
+*: <code>systemctl enable / disable</code>コマンドに関連する設定を記述する。
+* [Service]セクション
+*: 固有の設定項目を記述する。
+<br>
+オプションに複数の項目を記述する時は、スペース区切り、または、同じオプションを複数回に分けて記述する。<br>
+ # スペース区切り
+ After=NetworkManager.service systemd-resolved.service
+ # 複数回に分ける
+ After=NetworkManager.service
+ After=systemd-resolved.service
 <br>
 * [Unit]セクション
@@ 113行目: / 127行目: @@
 **: <u>"起動が完了する"</u>とは、次の他ユニットが実行可能であることを意味する。
 *** simple
-***: デフォルト。プロセスが起動した時点で起動が完了する。
+***: デフォルト。コマンドを実行した時点で起動完了と判定する。
+***: 指定コマンドがフォアグラウンドで実行を継続する場合に使用する。
 *** forking
-***: フォークして親プロセスが終了した時点で起動が完了する。
+***: 子プロセスをバックグラウンドで起動して、親プロセスが終了した時点(最初のコマンドが終了した時点)で起動完了と判定する。
+***: 最初のコマンドが終了する場合に使用する。
 *** oneshot
-***: simpleと似ているが、次のユニットを実行する前に自身のプロセスを終了する。
+***: simpleと似ているが、次のユニットを実行する前に自身のプロセスを終了する。(コマンドが終了したら起動完了と判定して、サービスも終了したものと認識する)
+***: <code>RemainAfterExit=yes</code>を指定する場合は、コマンド終了後もサービスは起動したままと認識する。
+***: 1度だけコマンドを実行するタイプの場合に使用する。
 *** dbus
-***: D-Busを使用するプロセスであり、D-Busの接続名を見つけた時に起動が完了する。
+***: D-Bus(プロセス間通信用メッセージバス)を使用するプロセスであり、<code>BusName</code>で指定した接続名がD-Busに登録される時点で起動完了と判定する。
 *** notify
-***: simpleと似ているが、<code>sd_notify</code>関数で起動完了のメッセージを受信した時に起動が完了する。
+***: simpleと似ているが、systemdのライブラリ関数である<code>sd_notify</code>関数を使用して、起動完了のメッセージを受信した時に起動が完了する。
+***: コマンドのプログラムにおいて、<code>sd_notify</code>関数を使用して起動完了を通知するように設計されている必要がある。
 *** idle
 ***: simpleと似ているが、他のジョブが終了するまで待機する。（シェルへの出力が混ざらないようにするため）
@@ 131行目: / 150行目: @@
 **: リロード時に実行するコマンドを記述する。
 ** Restart
-**: プロセスが停止した時、プロセスを再起動する条件を記述する。
+**: プロセスが異常終了した時、プロセスを再起動する条件を記述する。
+**: 未指定の場合、<u>10秒の間に5回以上再起動すると、次の10秒間は再起動を試みない。</u>
+**: <br>
+**: <code>StartLimitInterval</code>秒の間に<code>StartLimitBurst</code>回以上再起動すると、次の<code>StartLimitInterval</code>秒の間は再起動を試みない。
+**: <br>
 **: 各条件は以下の4つがある。
 *** always
@@ 240行目: / 263行目: @@
 指定したユニットよりも後に起動するユニットを表示する。<br>
   sudo systemctl list-dependencies <ユニット名> --before
+<br><br>
+== ユニットの有効化 / 無効化 ==
+指定のユニットを有効化および無効化する。<br>
+<br>
+maskを使用する場合、<code>sudo systemctl disable</code>と異なり、<code>sudo systemctl start</code>での手動起動もできなくなる。<br>
+maskによる無効化は、/etc/systemd/systemディレクトリ下に/dev/nullへのシンボリックリンクを張ることにより行われる。<br>
+<br>
+また、/etc/systemd/systemディレクトリ下に設定ファイルを作成している場合は、maskによる無効化はできない。<br>
+ sudo systemctl mask <ユニット名>
+ # または
+ sudo systemctl unmask <ユニット名>
+<br><br>
+== サービスの遅延実行 ==
+Systemdサービスを遅延起動する方法には、主に2つの方法がある。<br>
+<u>ただし、タイマユニットを使用する方法が一般的であり、より柔軟性が高い。</u><br>
+* Systemdのタイマーユニットを使用する方法
+* Systemdサービスファイル自体に遅延を設定する方法
+<br>
+==== タイマユニットを使用する方法 ====
+まず、実行するコマンドまたはプログラムを起動するSystemdサービスファイルを作成する。<br>
+ <syntaxhighlight lang="ini">
+ [Unit]
+ Description=My delayed service
+ [Service]
+ ExecStart=<実行するコマンドまたはプログラムのパス> [コマンドまたはプログラムのオプション]
+ </syntaxhighlight>
+<br>
+次に、特定のSystemdサービスファイルをどのタイミングで起動するかを指定するタイマファイルを作成する。<br>
+ <syntaxhighlight lang="ini">
+ [Unit]
+ Description=Timer for my service
+ [Timer]
+ OnBootSec=30      # 30秒後に起動する場合
+ #OnBootSec=10min  # 10分後に起動する場合
+ OnUnitActiveSec=24h      # サービスが最後にアクティブになってから24時間後に再びサービスを起動する （繰り返し実行する場合）
+ Unit=<タイマ起動するsystemdサービスファイル名>
+ [Install]
+ WantedBy=timers.target   # タイマをシステムのタイマターゲットに関連付けて、システム起動時にタイマを有効にする
+ </syntaxhighlight>
+<br>
+Systemdサービスファイルとタイマファイルを、/etc/systemd/systemディレクトリ、または、~/.config/systemd/userディレクトリに配置する。<br>
+Systemdサービスのデーモンを再読み込みする。<br>
+ # /etc/systemd/systemディレクトリに保存した場合
+ sudo systemctl daemon-reload
+ # ~/.config/systemd/userディレクトリに保存した場合
+ systemctl --user daemon-reload
+<br>
+タイマサービスを有効または開始する。<br>
+これにより、指定時間後にSystemdサービスが自動的に起動するようになる。<br>
+ # /etc/systemd/systemディレクトリに保存した場合
+ sudo systemctl enable <タイマファイル名  例: my_service.timer>  # 起動時に開始する場合
+ sudo systemctl start  <タイマファイル名  例: my_service.timer>  # 通常起動する場合
+ # ~/.config/systemd/userディレクトリに保存した場合
+ systemctl --user enable <タイマファイル名  例: my_service.timer>  # 起動時に開始する場合
+ systemctl --user start  <タイマファイル名  例: my_service.timer>  # 通常起動する場合
+<br>
+==== Systemdサービスファイル自体に遅延を設定する方法 ====
+Systemdサービスファイル内に<code>ExecStartPre</code>キーで時間を指定して、サービスの実行前に遅延 (例: <code>sleep</code>コマンドを使用) を挿入する方法もあるが、この方法は推奨されない。<br>
+これは、Systemdのタイマ機能を使用する方法と比較して、柔軟性に欠けることやシステムの起動プロセスを不必要に遅延させる可能性がある。<br>
+<br>
+そのため、タイマユニットを作成および使用して、サービスの起動タイミングを細かく制御することが推奨される。<br>
+<br><br>
+== Systemdサービスファイルの構文の確認 ==
+Systemdサービスファイル全体の構文を確認する。<br>
+これにより、問題のある部分を特定して、修正することができる。<br>
+ sudo systemd-analyze verify <Systemdサービスファイルまたはタイマファイル等のパス>
+<br>
+訂正後は、Systemdサービスファイルを再読み込みして、変更を有効にする。<br>
+ sudo systemctl daemon-reload
+ # または
+ systemctl --user daemon-reload
 <br><br>
@@ 340行目: / 442行目: @@
 <br>
 サービスユニットの状態を確認する。<br>
-sudo systemctl status <サービスユニットのファイル名>
+ sudo systemctl status <サービスユニットのファイル名>
+<br><br>
+== Journald ==
+Journaldの動作を、以下に示す。<br>
+# Rsyslogdへ出力する内容を、systemd-journald.service(Journald)に送信する。
+# Journaldはメタ情報を追加して、/var/log/journalディレクトリ下に記録する。
+# <code>journalctl</code>コマンドを使用して、Journaldのログ(バイナリ形式)を検索および表示する。
+<br>
+Systemdは、Rsyslogdの設定変更が必要となる。<br>
+* 従来の動作
+*: プロセス → /dev/log → Rsyslogd
+* Systemd
+*: プロセス → /dev/log → Systemd → /run/systemd/journal/syslog → Rsyslogd
+<br>
+また、Rsyslogdには、Journaldから直接ログ情報を取得するモジュールであるimjournalが存在しており、<br>
+UnixSocketである/run/systemd/journal/syslogファイルの代わりに、imjournalを利用することもできる。<br>
+<br>
+<code>journalctl</code>コマンドの便利なオプションを、以下に示す。<br>
+* -aオプション
+*: 長いメッセージを省略しない。
+* -bオプション
+*: 直前のサーバ起動以降のログを表示する。
+* -eオプション
+*: ページャーで最後にジャンプする。
+* -fオプション
+*: <code>tail -f</code>コマンドのように、順次表示する。
+* -uオプション
+*: 指定したユニットのログを表示する。
+* -xオプション
+*: メッセージの説明がある場合は追加する。
+* --since='YYYY-MM-DD hh:mm:ss'
+*: 指定日以降のログを表示する。
+* --until='YYYY-MM-DD hh:mm:ss'
+*: 指定日までのログを表示する。
+ # 例
+ sudo journalctl -ex -u <systemdサービスユニット名>
 <br><br>
 __FORCETOC__
-[[カテゴリ:CentOS]][[カテゴリ:SUSE]][[カテゴリ:Raspberry_Pi]][[カテゴリ:PinePhone]]
+[[カテゴリ:RHEL]][[カテゴリ:SUSE]][[カテゴリ:Raspberry_Pi]][[カテゴリ:PinePhone]]