15 systemdデーモン #

systemdは、System VおよびLSBのinitスクリプトと互換性のある、Linux向けのシステム/セッションマネージャです。 主な特長は次のとおりです。

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

systemd.unitの詳細については、http://www.freedesktop.org/software/systemd/man/systemd.unit.htmlを参照してください。

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

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

tux > sudo systemctl start MY_1ST_SERVICE MY_2ND_SERVICE

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

tux > 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またはコマンドラインを使用して実行できます。

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

 

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

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

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

表 15.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では、この設定が使用されることはありません。独自のブート可能なターゲットを作成する方法については、15.5.3項 「カスタムターゲットの作成」を参照してください。

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

root # 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'.

root # 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

tux > dmesg -T | less

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

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

systemdユニットファイルは、/usr/lib/systemd/systemにあります。サービスファイルをカスタマイズする場合は、次の手順に従います。

ファイル名が同じ場合、/etc/systemdにある変更済みファイルが、/usr/lib/systemd/systemにある元のファイルよりも優先的に使用されます。

root # 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
}

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

[Install]
WantedBy=sockets.target

root # 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

設定ファイルに何行かを追加したり、設定ファイルのごく一部を変更するには、「ドロップイン」と呼ばれるファイルを使用します。ドロップインファイルを使用すると、ユニットファイルの設定を拡張できます。その際に、ユニットファイル自体は編集も上書きもされません。

たとえば、/usr/lib/systemd/system/FOOBAR.SERVICEにあるFOOBARサービスの1つの値を変更するには、次の手順に従います。

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のステータスを取得するには、以下のようにします。

tux > 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を参照してください。

15.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コマンドを使用します。次の例のような結果になります(一部省略しています)。

root # 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を参照してください。

15.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コマンドに似た動作をするほか、ログメッセージをさまざまな形式で表示することもできます。これにより、強力なデバッグツールとして利用できるようになっています。