19 systemdデーモン #

ユニット設定ファイルには、サービス、ソケット、デバイス、マウントポイント、自動マウントポイント、スワップファイルやパーティション、起動ターゲット、監視対象のファイルシステムのパス、systemdによって制御および監視されているタイマ、一時的なシステム状態のスナップショット、リソース管理スライス、または外部で作成されたプロセスグループに関する情報が含まれます。

「ユニットファイル」は、systemdの次のファイルの総称です。

systemdユニットファイルの詳細については、https://www.freedesktop.org/software/systemd/man/latest/systemd.unit.htmlを参照してください。

サービスを管理するためのサブコマンドは、System V initでのサービス管理コマンドと同じ(start、stopなど)です。サービス管理コマンドの基本構文は、以下のとおりです。

systemdでは、複数のサービスを一括で管理できます。initスクリプトを次々と実行しなければならないSystem V initとは異なり、次のようにコマンドを実行します。

> sudo systemctl start MY_1ST_SERVICE MY_2ND_SERVICE

システムで利用できるすべてのサービスを一覧表示するには、次のように実行します。

> sudo systemctl list-unit-files --type=service

次の表に、systemdとSystem V initの最も重要なサービス管理コマンドを示します。

start

start

stop

stop

restart

restart

try-restart

try-restart

reload

reload

reload-or-restart

n/a

reload-or-try-restart

n/a

status

status

is-active

status

上述のサービス管理コマンドでは、現在のセッションに対するサービスを操作できます。systemdでは、サービスを恒久的に有効化/無効化して、必要に応じて自動的に起動したり、常に使用不可にすることもできます。この作業は、YaSTまたはコマンドラインを使用して実行できます。

19.2.2.1 コマンドラインからのサービスの有効化/無効化 #

 

次の表に、systemdとSystem V initの有効化/無効化コマンドを示します。

重要: サービスの起動について

コマンドラインからサービスを有効化した場合、そのサービスは自動的には起動されず、次回のシステム起動またはランレベル/ターゲット変更の際に起動されます。有効化した後で、即時にサービスを起動するには、systemctl start MY_SERVICEまたはrc MY_SERVICE startのように、明示的にサービスを起動してください。

表 19.2: サービスの有効化/無効化コマンド #

 

タスク	systemd コマンド	System V initコマンド
有効化.	systemctl enable MY_SERVICE(S)	insserv MY_SERVICE(S)、chkconfig -a MY_SERVICE(S)
無効化.	systemctl disable MY_SERVICE(S).service	insserv -r MY_SERVICE(S)、chkconfig -d MY_SERVICE(S)
確認.  サービスが有効になっているかどうかを示します。	systemctl is-enabled MY_SERVICE	chkconfig MY_SERVICE
再有効化.  サービスの再起動と同様に、このコマンドはいったんサービスを無効化した後に有効化します。サービスにデフォルト値を設定して再有効化する場合に利用します。	systemctl reenable MY_SERVICE	該当なし
マスク.  サービスを「無効化」しても、手動で起動できてしまいます。サービスを無効化するには、マスクを設定する必要があります。注意してご使用ください。	systemctl mask MY_SERVICE	該当なし
マスク解除.  マスクを設定したサービスは、マスクを解除しないと使用できません。	systemctl unmask MY_SERVICE	該当なし

System V initでは、システムは「ランレベル」と呼ばれる状態でブートしていました。ランレベルはシステムの起動方法および稼働中のシステムで使用可能なサービスを定義します。ランレベルは番号付けされています。よく知られているランレベルは、0 (システムのシャットダウン)、3 (ネットワークを使用するマルチユーザシステム)、および5 (ネットワークとディスプレイマネージャを使用するマルチユーザシステム)です。

systemdでは、「ターゲットユニット」と呼ばれる仕組みを使用する新しい概念が導入されています。ただし、ランレベルの概念とも、完全な互換性を維持しています。ターゲットユニットには、番号ではなく名前が付けられており、特定の目的を果たします。たとえば、ターゲットlocal-fs.targetやswap.targetは、それぞれローカルファイルシステムのマウントと、スワップ領域のマウントを実行します。

ターゲットgraphical.targetは、ネットワーク機能とディスプレイマネージャ機能を使用するマルチユーザシステムで、ランレベル5に相当します。graphical.targetなどの複合ターゲットは、他のターゲットのサブセットを組み合わせることで、「メタ」ターゲットとして機能します。systemdでは、既存のターゲットを組み合わせることで簡単にカスタムターゲットを作成できるため、非常に柔軟な運用が実現されます。

次のリストは、systemdの最も重要なターゲットユニットを示しています。すべてを網羅したリストについては、man 7 systemd.specialを参照してください。

System V initランレベルシステムとの互換性を維持するために、systemdでは、runlevelX.targetという名前の特別なターゲットが用意されています。それぞれXの部分がランレベルの番号に対応します。

現在のターゲットを検査するには、systemctl get-defaultコマンドを使用します。

重要: systemdは/etc/inittabを無視する

System V initシステムのランレベルは、/etc/inittabで設定されています。systemdでは、この設定が使用されることはありません。独自のブート可能なターゲットを作成する方法については、19.5.5項 「カスタムターゲットの作成」を参照してください。

systemdには、システム起動プロセスを分析できる機能が用意されています。この機能により、全サービスのリストとそのステータスを(/var/log/を解析することなく)確認することができます。systemdでは、起動手順を精査して、サービスの起動にかかっている時間を調べることもできます。

# systemctl
UNIT                        LOAD   ACTIVE SUB       JOB DESCRIPTION
[...]
iscsi.service               loaded active exited    Login and scanning of iSC+
kmod-static-nodes.service   loaded active exited    Create list of required s+
libvirtd.service            loaded active running   Virtualization daemon
nscd.service                loaded active running   Name Service Cache Daemon
chronyd.service             loaded active running   NTP Server Daemon
polkit.service              loaded active running   Authorization Manager
postfix.service             loaded active running   Postfix Mail Transport Ag+
rc-local.service            loaded active exited    /etc/init.d/boot.local Co+
rsyslog.service             loaded active running   System Logging Service
[...]
LOAD   = Reflects whether the unit definition was properly loaded.
ACTIVE = The high-level unit activation state, i.e. generalization of SUB.
SUB    = The low-level unit activation state, values depend on unit type.

161 loaded units listed. Pass --all to see loaded but inactive units, too.
To show all installed unit files use 'systemctl list-unit-files'.

# systemctl --failed
UNIT                   LOAD   ACTIVE SUB    JOB DESCRIPTION
apache2.service        loaded failed failed     apache
NetworkManager.service loaded failed failed     Network Manager
plymouth-start.service loaded failed failed     Show Plymouth Boot Screen

[...]

systemd.log_level=debug systemd.log_target=kmsg

> dmesg -T | less

systemdはSystem Vと互換性があるため、引き続き既存のSystem V initスクリプトを使用できます。ただし、そのままではsystemdでSystem V initスクリプトを使用できない既知の問題が少なくとも1つあります。initスクリプトでsuまたはsudoを使用して別のユーザとしてサービスを起動すると、スクリプトエラーになり、「アクセス拒否」エラーが生成されます。

suまたはsudoを使用してユーザを変更すると、PAMセッションが開始されます。このセッションは、initスクリプトが完了すると終了します。その結果、initスクリプトで起動されたサービスも終了します。このエラーを回避するには、次の手順に従います。

SUSEによって提供されるsystemdユニットファイルは、/usr/lib/systemd/に保存されています。カスタマイズされたユニットファイルとユニットファイルの「ドロップイン」は、/etc/systemd/に保存されています。

警告: カスタマイズが上書きされないようにする

systemdをカスタマイズする場合は、/usr/lib/systemd/ではなく、/etc/systemd/ディレクトリを必ず使用してください。そうしないと、systemdの次回の更新によって、変更内容が上書きされてしまいます。

ドロップインファイル(または「ドロップイン」)は、ユニットファイルの特定の設定のみを上書きする部分的なユニットファイルです。ドロップインは、メイン設定ファイルより優先されます。コマンドsystemctl edit SERVICEはデフォルトのテキストエディタを起動し、/etc/systemd/system/NAME.service.d/に空のoverride.confファイルを含むディレクトリを作成します。また、このコマンドは、実行中のsystemdプロセスに変更について通知するようにします。

たとえば、システムがMariaDBを起動するまで待機する時間を変更するには、sudo systemctl edit mariadb.serviceを実行し、開いたファイルを編集して、変更した行のみを含めます。

# Configures the time to wait for start-up/stop
TimeoutSec=300

TimeoutSecの値を調整して、変更を保存します。変更を有効にするには、sudo systemctl daemon-reloadを実行します。

詳細については、man 1 systemctlコマンドで呼び出すことが可能なマニュアルページを参照してください。

警告: フルユニットファイルのコピーの作成

systemctl edit --full SERVICEコマンドで--fullオプションを使用すると、元のユニットファイルのコピーが作成され、特定のオプションを変更できます。SUSEでユニットファイルが更新されると、その変更は、/etc/systemd/system/ディレクトリのカスタマイズされたコピーによって上書きされるため、このようなカスタマイズはお勧めしません。さらに、SUSEがディストリビューションのドロップインに更新を提供する場合、--fullで作成されたユニットファイルのコピーが上書きされます。この混乱を回避し、常にカスタマイズを有効にするには、ドロップインを使用します。

systemctl editコマンドを使用するのとは別に、優先度をより細かく制御できるように、ドロップインを手動で作成できます。このようなドロップインを使用すると、ファイル自体を編集したり、上書きしたりせずに、ユニットとデーモン両方の設定ファイルを拡張できます。次のディレクトリに保存されます。

ヒント

ユニット検索パスのフルリストについては、man 5 systemd.unitのマニュアルページを参照してください。

たとえば、systemd-journaldのデフォルト設定によって適用されるレート制限を無効にするには、次の手順に従います。

注記: 名前の競合を回避する

ドロップインファイルとSUSEによって提供されるファイルとの間の名前の競合を回避するために、すべてのドロップインの前に2桁の数字とダッシュを付けることをお勧めします(たとえば、80-override.conf)。

次の範囲が予約されています。

• 0-19は、systemdアップストリーム用に予約されています。

• 20-29は、SUSEによって提供されるsystemd用に予約されています。

• 30-39は、systemd以外のSUSEパッケージ用に予約されています。

• 40-49は、サードパーティのパッケージ用に予約されています。

• 50は、systemctl set-propertyを使用して作成されたユニットドロップインファイル用に予約されています。

この範囲を超える2桁の数字を使用して、SUSEによって提供されるドロップインが独自のドロップインを上書きしないようにします。

ヒント

systemctl cat $UNITを使用して、ユニット設定で考慮されるファイルを一覧表示し、確認することができます。

ヒント

systemdコンポーネントの設定は、ファイルシステムのさまざまな場所に分散している可能性があるため、全体的な概要を把握するのが難しい場合があります。systemdコンポーネントの設定を調べるには、次のコマンドを使用します。

• systemctl cat UNIT_PATTERNは、1つ以上のsystemdユニットに関連する設定ファイルを出力します。次に例を示します。

  > systemctl cat atd.service

• systemd-analyze cat-config DAEMON_NAME_OR_PATHは、systemdデーモンの設定ファイルとドロップインのコンテンツをコピーします。次に例を示します。

  > systemd-analyze cat-config systemd/journald.conf

SUSE Linux Enterprise Server 15のリリース以降、xinetdインフラストラクチャは削除されました。このセクションでは、既存のカスタムxinetdサービスファイルを、systemdソケットに変換する方法の概要を説明します。

xinetdサービスファイルごとに、少なくとも2つのsystemdユニットファイル(ソケットファイル(*.socket)および関連するサービスファイル(*.service))が必要です。ソケットファイルはどのソケットを作成するかをsystemdに指示し、サービスファイルはどの実行可能ファイルを起動するかをsystemdに指示します。

次のようなxinetdサービスファイルの例を考えてみます。

# cat /etc/xinetd.d/example
service example
{
  socket_type = stream
  protocol = tcp
  port = 10085
  wait = no
  user = user
  group = users
  groups = yes
  server = /usr/libexec/example/exampled
  server_args = -auth=bsdtcp exampledump
  disable = no
}

systemdに変換するには、以下の2つの一致するファイルが必要です。

# cat /usr/lib/systemd/system/example.socket
[Socket]
ListenStream=0.0.0.0:10085
Accept=false

[Install]
WantedBy=sockets.target

# cat /usr/lib/systemd/system/example.service
[Unit]
Description=example

[Service]
ExecStart=/usr/libexec/example/exampled -auth=bsdtcp exampledump
User=user
Group=users
StandardInput=socket

systemd 「socket」と「service」ファイルオプションの完全なリストについては、systemd.socketおよびsystemd.serviceのマニュアルページ(man 5 systemd.socket、man 5 systemd.service)を参照してください。

System V init SUSEシステムでは、管理者が独自のランレベル設定を作成できるように、ランレベル4は使用されていません。systemdでは、任意の数のカスタムターゲットを作成できます。ターゲットの作成は、graphical.targetなどの既存のターゲットを改変することから始めることをお勧めします。

systemdによって、定期的に一時ディレクトリを消去できます。前バージョンのシステムの設定は、自動的に移行されアクティブになります。一時ファイルを管理するtmpfiles.dは、/etc/tmpfiles.d/*.conf、/run/tmpfiles.d/*.conf、および/usr/lib/tmpfiles.d/*.confファイルからその設定を読み込みます。/etc/tmpfiles.d/*.confにある設定は、他の2つのディレクトリにある関連設定より優先します(/usr/lib/tmpfiles.d/*.confには、パッケージの設定ファイルが保存されています)。

設定のフォーマットは、パスごとに1行で、アクション、パス、およびオプションでモード、所有権、経過時間、引数のフィールドが含まれています(アクションによって変わります)。次の例は、X11ロックファイルのリンクを解除します。

Type Path               Mode UID  GID  Age Argument
r    /tmp/.X[0-9]*-lock

tmpfile timerのステータスを取得するには、以下のようにします。

> sudo systemctl status systemd-tmpfiles-clean.timer
systemd-tmpfiles-clean.timer - Daily Cleanup of Temporary Directories
 Loaded: loaded (/usr/lib/systemd/system/systemd-tmpfiles-clean.timer; static)
 Active: active (waiting) since Tue 2018-04-09 15:30:36 CEST; 1 weeks 6 days ago
   Docs: man:tmpfiles.d(5)
         man:systemd-tmpfiles(8)

Apr 09 15:30:36 jupiter systemd[1]: Starting Daily Cleanup of Temporary Directories.
Apr 09 15:30:36 jupiter systemd[1]: Started Daily Cleanup of Temporary Directories.

一時ファイルの処理について詳しくは、man 5 tmpfiles.dを参照してください。

19.6.9項 「サービスのデバッグ」には、特定のサービスに対するログメッセージを閲覧する方法が説明されていますが、表示されるログメッセージは、サービスログからのものだけであるとは限りません。systemdが記録したすべてのログメッセージ(「ジャーナル」と呼ばれる)にアクセスして問い合わせることもできます。最も古いログから始めて、すべてのログメッセージを表示するには、journalctlコマンドを使用します。フィルタの適用や出力形式の変更については、man 1 journalctlを参照してください。

systemdの現在の状態を名前付きのスナップショットに保存し、後でisolateサブコマンドを使用してその状態に戻ることができます。定義した状態にいつでも戻ることができるため、サービスやカスタムターゲットをテストする際に便利です。スナップショットは現在のセッションでのみ使用可能で、システムを再起動すると自動的に削除されます。スナップショットの名前は、.snapshotで終わる必要があります。

systemdにより、/etc/modules-load.dにある環境設定ファイルを使用してブート時に自動的にカーネルモジュールをロードできます。このファイルはMODULE.confという名前で、次のような内容です。

# load module MODULE at boot time
MODULE

カーネルモジュールをロードするための設定ファイルがパッケージによってインストールされる場合、そのファイルは/usr/lib/modules-load.dにインストールされます。同じ名前の環境設定ファイルが2つ存在する場合、/etc/modules-load.dにあるファイルが優先されます。

詳細については、modules-load.d(5)のマニュアルページを参照してください。

System Vでは、サービスをロードする前に実行する必要のあるinitアクションは、/etc/init.d/before.local に指定する必要がありました。この手順は、systemdではサポートされません。サービスの起動前にアクションを実行する必要がある場合、以下のようにしてください。

従来のSystem V initシステムでは、特定のプロセスを、その生成元のサービスと一致させることができないことがありました。Apacheなどの特定のサービスは、サードパーティのプロセス(CGIやJavaのプロセスなど)を多数生成し、サードパーティのプロセス自体もさらにプロセスを生成します。サービスに対する明確な割り当ては難しいことがあるだけでなく、場合によっては不可能であることもあります。特定の子プロセスを残して、サービスが正しく終了しないことも考えられます。

systemdでは、各プロセスを独自のcgroupに配置することでこの問題を解決しています。cgroupはプロセスをまとめるためのカーネルの機能で、すべての子プロセスを階層構造のグループとして管理します。systemdでは、各cgroupにそのサービスの名前が付けられています。非特権プロセスではcgroupから「離脱」できないため、サービスから生成したプロセスがどれなのかをサービス名によって判別できる効果的な仕組みです。

サービスに属するすべてのプロセスを表示するには、systemd-cglsコマンドを使用します。次に例を示します。

# systemd-cgls --no-pager
├─1 /usr/lib/systemd/systemd --switched-root --system --deserialize 20
├─user.slice
│ └─user-1000.slice
│   ├─session-102.scope
│   │ ├─12426 gdm-session-worker [pam/gdm-password]
│   │ ├─15831 gdm-session-worker [pam/gdm-password]
│   │ ├─15839 gdm-session-worker [pam/gdm-password]
│   │ ├─15858 /usr/lib/gnome-terminal-server

[...]

└─system.slice
  ├─systemd-hostnamed.service
  │ └─17616 /usr/lib/systemd/systemd-hostnamed
  ├─cron.service
  │ └─1689 /usr/sbin/cron -n
  ├─postfix.service
  │ ├─ 1676 /usr/lib/postfix/master -w
  │ ├─ 1679 qmgr -l -t fifo -u
  │ └─15590 pickup -l -t fifo -u
  ├─sshd.service
  │ └─1436 /usr/sbin/sshd -D

[...]

cgroupの詳細については、Chapter 10, Kernel control groupsを参照してください。

19.6.6項 「カーネルのコントロールグループ(cgroup)」で説明したとおり、System V initのシステムでは、プロセスをその親サービスプロセスに割り当てることができないことがあります。そのため、サービスとその子プロセスを停止するのが難しくなります。終了されていない子プロセスは、ゾンビプロセスとして残ってしまいます。

各サービスをcgroupに範囲制約するという、systemdの概念を採用することで、サービスのすべての子プロセスを判別し、それら各プロセスに対してシグナルを送信できます。サービスに対してシグナルを送信する場合は、systemctl killコマンドを使用します。使用可能なシグナルの一覧については、man 7 signalsを参照してください。

D-Busサービスは、systemdクライアントと、pid 1として実行されるsystemdマネージャ間の通信用のメッセージバスです。dbusはスタンドアロンのデーモンですが、初期化インフラストラクチャの不可欠な要素です。

動作中のシステムでdbusを停止または再起動することは、PID 1の停止または再起動と同様の結果をもたらします。これにより、systemdクライアント/サーバ通信が切断され、ほとんどのsystemd機能が使用できなくなります。

したがって、dbusの終了または再起動は推奨されず、サポートもされません。

dbusまたはdbusに関連するパッケージを更新するには、再起動する必要があります。再起動が必要かどうか疑問に思う場合は、sudo zypper ps -sコマンドを実行します。dbusが一覧表示されているサービスに表示される場合は、システムを再起動する必要があります。

自動更新が再起動が必要なパッケージをスキップするように設定されている場合でも、dbusは更新されることに留意してください。

デフォルトでは、systemdは過剰に冗長な出力を行いません。サービスの起動が成功した場合は何も出力されず、失敗した場合は短いエラーメッセージが表示されます。ただし、systemctl statusは、サービスの起動と動作をデバッグする手段を提供します。

systemdは、独自のログ機構(「ジャーナル」)でシステムメッセージを記録します。これにより、サービスメッセージとステータスメッセージを両方とも表示できます。statusコマンドはtailコマンドに似た動作をするほか、ログメッセージをさまざまな形式で表示することもできます。これにより、強力なデバッグツールとして利用できるようになっています。

タイマユニットは、単調タイマとリアルタイムタイマを使用できます。

すべてのタイマユニットには、それが制御する対応するsystemdユニットファイルが必要です。つまり、.timerファイルは、対応する.serviceファイルを有効にし、管理します。タイマとともに使用する場合、.serviceファイルには[Install]セクションは必要ありません。サービスがタイマによって管理されるためです。

systemdタイマユニットの基本を理解するために、foo.shシェルスクリプトをトリガするタイマを設定します。

最初のステップは、シェルスクリプトを制御するsystemdサービスユニットを作成することです。このファイルを作成するには、編集用に新しいテキストファイルを開いて、次のサービスユニット定義を追加します。

[Unit]
Description="Foo shell script"

[Service]
ExecStart=/usr/local/bin/foo.sh

ファイルをfoo.serviceという名前で/etc/systemd/system/ディレクトリに保存します。

次に、編集用に新しいテキストファイルを開いて、次のタイマ定義を追加します。

[Unit]
Description="Run foo shell script"

[Timer]
OnBootSec=5min
OnUnitActiveSec=24h
Unit=foo.service

[Install]
WantedBy=multi-user.target

上記の例の[Timer]セクションは、トリガするサービス(foo.service)とトリガするタイミングを指定します。この場合、オプションOnBootSecはシステム起動の5分後にサービスをトリガする単調タイマを指定し、オプションOnUnitActiveSecはサービスが有効になってから24時間後にサービスをトリガします(つまり、タイマは1日に1回サービスをトリガします)。最後に、オプションWantedByはシステムがマルチユーザターゲットに到達したときに、タイマが開始されるように指定します。

単調タイマの代わりに、オプションOnCalendarを使用してリアルタイムタイマを指定できます。次のリアルタイムタイマ定義は週に1回、月曜日の12時に関連するサービスをトリガします。

[Timer]
OnCalendar=weekly
Persistent=true

オプションPersistent=trueは、タイマが最後の開始時刻を逃した場合(たとえば、システムの電源がオフになっているため)、タイマが有効化された直後にサービスがトリガされることを示します。

オプションOnCalendarを使用して、次の形式で、サービスをトリガするための特定の日時を定義することもできます。DayOfWeek Year-Month-Day Hour:Minute:Second。次の例は、毎日午前5時にサービスをトリガします。

OnCalendar=*-*-* 5:00:00

アスタリスクで任意の値を指定し、カンマで可能な値を列挙することができます。.. によって区切られた2つの値を使用して、連続した範囲を示します。次の例は毎月金曜日の午後6時にサービスをトリガします。

OnCalendar=Fri *-*-1..7 18:00:00

異なる時間にサービスをトリガするために、複数のOnCalendarエントリを指定できます。

OnCalendar=Mon..Fri 10:00
OnCalendar=Sat,Sun 22:00

上記の例では、平日は午前10時、週末は午後10時にサービスがトリガされます。

タイマユニットファイルの編集が終了したら、foo.timerという名前で/etc/systemd/system/ディレクトリに保存します。作成したユニットファイルが正しいかどうかを確認するには、次のコマンドを実行します。

> sudo  systemd-analyze verify /etc/systemd/system/foo.*

コマンドが出力を返さない場合、ファイルは検証に成功しています。

タイマを開始するには、コマンドsudo systemctl start foo.timerを使用します。起動時にタイマを有効にするには、コマンドsudo systemctl enable foo.timerを使用します。

タイマは通常のsystemdユニットとして扱われるため、systemctlを使用して管理できます。たとえば、systemctl startでタイマを起動し、systemctl enableでタイマを有効にできます。また、コマンドsystemctl list-timersを使用して、すべてのアクティブタイマを一覧表示できます。非アクティブなタイマを含むすべてのタイマを一覧表示するには、コマンドsystemctl list-timers --allを実行します。