13 systemd
デーモン #
プログラムsystemd
は、プロセスID 1のプロセスであり、要求された方法でシステムを初期化します。systemd
はカーネルによって直接起動され、通常はプロセスを強制終了するシグナル9が使えないようにします。他のすべてのプログラムは、systemdまたは子プロセスのいずれかによって直接起動されます。
SUSE Linux Enterprise Server 12から、systemdが一般的なSystem V initデーモンに取って代わりました。systemd
は、System V initと完全な互換性があります(initスクリプトをサポートしているため)。systemdの主な利点の1つは、サービスを積極的に並行起動することで、ブート時間をかなり速くできることです。systemdは、サービスを必要なときだけ起動します。デーモンは、ブート時に無条件で起動されることはなく、最初に必要になったときに起動されます。systemdでは、カーネルのコントロールグループ(cgroup)もサポートしているほか、システムの状態をスナップショットに保存したり、その状態に復元したりすることもできます。詳細については、http://www.freedesktop.org/wiki/Software/systemd/を参照してください。
13.1 systemdの概念 #
このセクションでは、systemdの背景にある概念について詳しく説明します。
13.1.1 systemdについて #
systemdは、System VおよびLSBのinitスクリプトと互換性のある、Linux向けのシステム/セッションマネージャです。 主な特長は次のとおりです。
積極的な並行機能の提供
ソケットやD-Busアクティベーションを使用したサービスの起動
デーモンのオンデマンド起動
Linux cgroupsを使用したプロセスの追跡
システム状態のスナップショットへの保存、およびその状態への復元
マウントポイントと自動マウントポイントの保持
精巧なトランザクションの依存関係に基づくサービス制御ロジックの実装
13.1.2 ユニットファイル #
ユニット設定ファイルには、サービス、ソケット、デバイス、マウントポイント、自動マウントポイント、スワップファイルやパーティション、起動ターゲット、監視対象のファイルシステムのパス、systemdによって制御および監視されているタイマ、一時的なシステム状態のスナップショット、リソース管理スライス、または外部で作成されたプロセスグループに関する情報が含まれます。「ユニットファイル」は、systemdの次のファイルの総称です。
サービス. プロセスに関する情報(たとえば、実行中のデーモン)。サービスファイルは.serviceで終わります。
ターゲット. システム起動時のユニットのグループ化に、または同期ポイントとして使用されます。ターゲットファイルは.targetで終わります。
ソケット. ソケットに基づくアクティベーション(
inetd
など)でのIPC、ネットワークソケット、ファイルシステムFIFOに関する情報。ソケットファイルは.socketで終わります。パス. その他のユニットをトリガするために使用されます(たとえば、ファイル変更時のサービスの実行など)。パスファイルは.pathで終わります。
タイマ. タイマ制御された、タイマに基づくアクティベーションに関する情報。タイマファイルは.timerで終わります。
マウントポイント. 通常はfstabジェネレータによって自動生成されます。マウントポイントファイルは.mountで終わります。
自動マウントポイント. ファイルシステムの自動マウントポイントに関する情報。自動マウントポイントファイルは.automountで終わります。
スワップ. スワップデバイスに関する情報またはメモリページング用のファイル。スワップファイルは.swapで終わります。
デバイス. sysfs/udev(7)デバイスツリーに公開されているデバイスユニットに関する情報。デバイスファイルは.deviceで終わります。
スコープ/スライス. プロセスグループのリソースを階層管理する際の概念。スコープ/スライスファイルは.scope/.sliceで終わります。
systemd.unitの詳細については、http://www.freedesktop.org/software/systemd/man/systemd.unit.htmlを参照してください。
13.2 基本的な使用方法 #
System V initシステムでは、initスクリプト、insserv
、telinit
などの複数のコマンドを使用してサービスを処理します。systemdでは、サービスに対する主な処理を実行する際、1 つのコマンド(systemctl
)で済むようになっているため、サービスをより容易に管理できます。git
やzypper
のように、「コマンドの後ろにサブコマンド」を指定して実行します。
systemctl GENERAL OPTIONS SUBCOMMAND SUBCOMMAND OPTIONS
完全なマニュアルについては、man 1 systemctl
を参照してください。
systemdのコマンドは、出力先が端末である場合(パイプやファイルなどではない場合)、デフォルトではページャに長い出力が送信されます。ページングモードをオフにするには、--no-pager
オプションを使用してください。
systemdでは、bashによる補完もサポートしています。サブコマンドの最初の1文字を入力し、<Tab>を押すと、サブコマンドの残りを自動的に入力することができます。この機能は、bash
シェルを利用している場合にのみ使用できるもので、bash-completion
パッケージをインストールしておく必要があります。
13.2.1 稼働中のシステムでのサービスの管理 #
サービスを管理するためのサブコマンドは、 System V initでのサービス管理コマンドと同じ(start
、stop
など)です。サービス管理コマンドの基本構文は、以下のとおりです。
- systemd
systemctl reload|restart|start|status|stop|... MY_SERVICE(S)
- System V init
rcMY_SERVICE(S) reload|restart|start|status|stop|...
systemdでは、複数のサービスを一括で管理できます。initスクリプトを次々と実行しなければならないSystem V initとは異なり、次のようにコマンドを実行します。
systemctl start MY_1ST_SERVICE MY_2ND_SERVICE
システムで利用できるすべてのサービスを一覧表示するには、次のように実行します。
systemctl list-unit-files --type=service
次の表に、systemdとSystem V initの最も重要なサービス管理コマンドを示します。
タスク |
systemdコマンド |
System V initコマンド |
---|---|---|
起動. |
start |
start |
停止. |
stop |
stop |
再起動. サービスを停止し、後で起動します。サービスがまだ起動していない場合は、そのサービスを起動します。 |
restart |
restart |
条件付きの再起動. サービスが現在実行中の場合、サービスを再起動します。実行されていないサービスについては、何も行いません。 |
try-restart |
try-restart |
再ロード.
サービスに対し、操作を中断せずに設定ファイルを再ロードするように指示します。Apacheに、変更後の |
reload |
reload |
再ロードまたは再起動. サービスが再ロードをサポートしていれば再ロードし、サポートしていなければ再起動します。サービスがまだ起動していない場合は、そのサービスを起動します。 |
reload-or-restart |
n/a |
条件付きの再ロードまたは再起動. サービスが再ロードをサポートしていれば再ロードし、サポートしていなければ再起動します(現在実行中の場合)。実行されていないサービスについては、何も行いません。 |
reload-or-try-restart |
n/a |
詳細なステータス情報の取得.
サービスのステータスについて、情報を表示します。 |
status |
status |
簡潔なステータス情報の取得. サービスがアクティブかどうかを示します。 |
is-active |
status |
13.2.2 サービスの恒久的な有効化/無効化 #
上述のサービス管理コマンドでは、現在のセッションに対するサービスを操作できます。systemdでは、サービスを恒久的に有効化/無効化して、必要に応じて自動的に起動したり、常に使用不可にすることもできます。この作業は、YaSTまたはコマンドラインを使用して実行できます。
13.2.2.1 コマンドラインからのサービスの有効化/無効化 #
次の表に、systemdとSystem V initの有効化/無効化コマンドを示します。
コマンドラインからサービスを有効化した場合、そのサービスは自動的には起動されず、次回のシステム起動またはランレベル/ターゲット変更の際に起動されます。有効化した後で、即時にサービスを起動するには、systemctl start MY_SERVICE
またはrc MY_SERVICE start
のように、明示的にサービスを起動してください。
作業 |
|
System V initコマンド |
---|---|---|
有効化. |
|
|
無効化. |
|
|
確認. サービスが有効になっているかどうかを示します。 |
|
|
再有効化. サービスの再起動と同様に、このコマンドはいったんサービスを無効化した後に有効化します。サービスにデフォルト値を設定して再有効化する場合に利用します。 |
|
該当なし |
マスク. サービスを「無効化」しても、手動で起動できてしまいます。サービスを完全に無効化するには、マスクを設定する必要があります。 注意してご使用ください。 |
|
該当なし |
マスク解除. マスクを設定したサービスは、マスクを解除しないと使用できません。 |
|
該当なし |
13.3 システムの起動とターゲットの管理 #
システムを起動し、シャットダウンするプロセス全体は、systemdによって管理されます。この点から見ると、カーネルは、他のプログラムからの要求に従って、他のすべてのプロセスを管理し、CPU時間とハードウェアアクセスを調整するバックグラウンドプロセスと考えることができます。
13.3.1 ターゲットとランレベルの比較 #
System V initでは、システムは「ランレベル」と呼ばれる状態でブートしていました。ランレベルはシステムの起動方法および稼働中のシステムで使用可能なサービスを定義します。ランレベルは番号付けされています。よく知られているランレベルは、0
(システムのシャットダウン)、3
(ネットワークを使用するマルチユーザシステム)、および5
(ネットワークとディスプレイマネージャを使用するマルチユーザシステム)です。
systemdでは、「ターゲットユニット」と呼ばれる仕組みを使用する新しい概念が導入されています。ただし、ランレベルの概念とも、完全な互換性を維持しています。ターゲットユニットには、番号ではなく名前が付けられており、特定の目的を果たします。たとえば、ターゲットlocal-fs.target
やswap.target
は、それぞれローカルファイルシステムのマウントと、スワップ領域のマウントを実行します。
ターゲットgraphical.target
は、ネットワーク機能とディスプレイマネージャ機能を使用するマルチユーザシステムで、ランレベル5に相当します。 graphical.target
などの複合ターゲットは、他のターゲットのサブセットを組み合わせることで、「メタ」ターゲットとして機能します。systemdでは、既存のターゲットを組み合わせることで簡単にカスタムターゲットを作成できるため、非常に柔軟な運用が実現されます。
次のリストは、systemdの最も重要なターゲットユニットを示しています。すべてを網羅したリストについては、man 7 systemd.special
を参照してください。
default.target
デフォルトで起動されるターゲット。「実在する」ターゲットというよりは、別のターゲット(
graphic.target
など)に対するシンボリックリンクであるといえます。YaSTを介して恒久的に変更できます(13.4項 「YaSTを使用したサービスの管理」を参照)。セッション用に変更する場合は、ブートプロンプトで、カーネルパラメータsystemd.unit=MY_TARGET.target
を使用してください。emergency.target
コンソール上で非常用のシェルを起動します。ブートプロンプトでのみ、
systemd.unit=emergency.target
と指定して使用します。graphical.target
ネットワークとマルチユーザをサポートし、ディスプレイマネージャを使用するシステムを起動します。
halt.target
システムをシャットダウンします。
mail-transfer-agent.target
メールの送受信に必要なすべてのサービスを起動します。
multi-user.target
ネットワークに対応したマルチユーザシステムを起動します。
reboot.target
システムを再起動します。
rescue.target
ネットワークに対応しないシングルユーザシステムを起動します。
System V initランレベルシステムとの互換性を維持するために、systemdでは、runlevelX.target
という名前の特別なターゲットが用意されています。それぞれXの部分がランレベルの番号に対応します。
現在のターゲットを知りたい場合は、systemctl get-default
コマンドを使用します。
systemd
のターゲットユニット #
System Vランレベル |
|
用途 |
---|---|---|
0 |
|
システムのシャットダウン |
1、S |
|
シングルユーザモード |
2 |
|
リモートネットワークなしのローカルマルチユーザ |
3 |
|
ネットワークを使用するフルマルチユーザ |
4 |
|
未使用/ユーザ定義 |
5 |
|
ネットワークとディスプレイマネージャを使用するフルマルチユーザ |
6 |
|
システムの再起動 |
/etc/inittab
が無視されることについて
System V initシステムのランレベルは、/etc/inittab
で設定されています。 systemdでは、この設定が使用されることはありません。独自のブート可能なターゲットを作成する方法については、13.5.3項 「カスタムターゲットの作成」を参照してください。
13.3.1.1 ターゲット変更用のコマンド #
次のコマンドを使用して、ターゲットユニットを操作します。
作業 |
systemdコマンド |
System V initコマンド |
---|---|---|
現在のターゲット/ランレベルの変更 |
|
|
デフォルトのターゲット/ランレベルへの変更 |
|
該当なし |
現在のターゲット/ランレベルの取得 |
systemdでは通常、複数のアクティブターゲットを利用します。そのため、このコマンドは現在アクティブなターゲットをすべて表示します。 |
または
|
デフォルトのランレベルの恒久的な変更 |
サービスマネージャを使用するか、次のコマンドを実行します。
|
サービスマネージャを使用するか、次の行を変更します。
( |
現在のブートプロセスに対するデフォルトランレベルの変更 |
ブートプロンプトで次のオプションを入力します。
|
ブートプロンプトで必要なランレベルの番号を入力します。 |
ターゲットやランレベルの依存関係の表示 |
「Requires」を指定すると、ハード依存関係(必ず解決する必要がある依存関係)が表示されます。「Wants」を指定すると、ソフト依存関係(可能であれば解決される依存関係)が表示されます。 |
該当なし |
13.3.2 システム起動のデバッグ #
systemdには、システム起動プロセスを分析できる機能が用意されています。この機能により、全サービスのリストとそのステータスを(/varlog/
を解析することなく)確認することができます。systemdでは、起動手順を精査して、サービスの起動にかかっている時間を調べることもできます。
13.3.2.1 サービスの起動の確認 #
システムのブート後に起動された全サービスのリストを確認するには、systemctl
と入力します。次のように、すべてのアクティブなサービスが表示されます (一部省略しています)。特定のサービスの詳細情報が必要な場合は、systemctl status MY_SERVICE
を使用してください。
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
ntpd.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'.
起動に失敗したサービスだけを表示する場合は、--failed
オプションを指定してください。
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
[...]
13.3.2.2 起動時間のデバッグ #
システムの起動時間をデバッグするために、systemdでは、systemd-analyze
コマンドが用意されています。このコマンドでは、全体の起動時間や起動時間順のサービス一覧を表示できるほか、他のサービスの起動時間と対比するために利用できる、SVG画像を生成することもできます。
- システムの起動時間の一覧表示
root #
systemd-analyze Startup finished in 2666ms (kernel) + 21961ms (userspace) = 24628ms- サービスの起動時間の一覧表示
root #
systemd-analyze blame 6472ms systemd-modules-load.service 5833ms remount-rootfs.service 4597ms network.service 4254ms systemd-vconsole-setup.service 4096ms postfix.service 2998ms xdm.service 2483ms localnet.service 2470ms SuSEfirewall2_init.service 2189ms avahi-daemon.service 2120ms systemd-logind.service 1210ms xinetd.service 1080ms ntp.service [...] 75ms fbset.service 72ms purge-kernels.service 47ms dev-vda1.swap 38ms bluez-coldplug.service 35ms splash_early.service- サービスの起動時間を表す画像
root #
systemd-analyze plot > jupiter.example.com-startup.svg
13.3.2.3 起動プロセス全体の確認 #
上述のコマンドを利用することで、起動したサービスと起動にかかった時間を確認できます。さらに詳しい情報が必要な場合は、ブートプロンプトで次のパラメータを入力することにより、systemd
に対して、起動手順全体の冗長ログを記録するように指示できます。
systemd.log_level=debug systemd.log_target=kmsg
systemd
が、ログメッセージをカーネルのリングバッファに書き込むようになります。バッファを閲覧するには、dmesg
を使用してください。
dmesg -T | less
13.3.3 System Vとの互換性 #
systemdはSystem Vと互換性があるため、引き続き既存のSystem V initスクリプトを使用できます。ただし、そのままではsystemdでSystem V initスクリプトを使用できない既知の問題が少なくとも1つあります。initスクリプトでsu
またはsudo
を使用して別のユーザとしてサービスを起動すると、スクリプトエラーになり、「アクセス拒否」エラーが生成されます。
su
またはsudo
を使用してユーザを変更すると、PAMセッションが開始されます。このセッションは、initスクリプトが完了すると終了します。その結果、initスクリプトで起動されたサービスも終了します。このエラーを回避するには、次の手順に従います。
initスクリプトと同じ名前を持ち、ファイル名拡張子
.service
が付くサービスファイルラッパーを作成します。[Unit] Description=DESCRIPTION After=network.target [Service] User=USER Type=forking1 PIDFile=PATH TO PID FILE1 ExecStart=PATH TO INIT SCRIPT start ExecStop=PATH TO INIT SCRIPT stop ExecStopPost=/usr/bin/rm -f PATH TO PID FILE1 [Install] WantedBy=multi-user.target2
大文字で記述されている値はすべて適切な値に置き換えてください。
systemctl start APPLICATION
でデーモンを起動します。
13.4 YaSTを使用したサービスの管理 #
基本的なサービス管理は、YaSTサービスマネージャモジュールで行うこともできます。このモジュールは、サービスの起動、停止、有効化、および無効化をサポートしています。サービスのステータスを表示したり、デフォルトのターゲットを変更することもできます。
› › の順に選択して、YaSTモジュールを起動します。- の変更
システムのブート先になるターゲットを変更するには、
ドロップダウンボックスからターゲットを選択します。最もよく使用されているターゲットは、 (グラフィカルなログイン画面を起動する)と (コマンドラインモードでシステムを起動する)です。- サービスの起動または停止
テーブルからサービスを選択します。
列は、現在サービスが実行されているかどうかを示します( か、 かを示します)。ステータスを切り替えるには、 を選択します。サービスを起動または停止すると、現在実行されているセッションのステータスが変更されます。再起動時にステータスを変更するには、サービスを有効化または無効化する必要があります。
- サービスの有効化または無効化
テーブルからサービスを選択します。
列は、現在サービスが されているか、それとも されているかを示します。ステータスを切り替えるには、 を選択します。サービスを有効化/無効化することにより、サービスがブート時に起動されるかどうか(
)または )を設定できます。この設定は、現在のセッションには影響しません。現在のセッションにおけるサービスのステータスを変更するには、サービスを起動または停止する必要があります。- ステータスメッセージの表示
サービスのステータスメッセージを表示するには、リストからサービスを選択し、
を選択します。表示される内容は、コマンドsystemctl
-l
status MY_SERVICEで生成されたものと同じです。
ランレベルの設定が誤っていると、システムを使用できなくなることがあります。変更を実際に適用する前に、どういう結果が出るかをよく確認してください。
13.5 systemd
のカスタマイズ #
以降の各項には、systemd
のカスタマイズ例が示されています。
systemdのカスタマイズは/etc/systemd/
で行ってください。/usr/lib/systemd/
では、絶対に行わないでください。そうしないと、systemdの次回の更新によって、変更内容が上書きされてしまいます。
13.5.1 サービスファイルのカスタマイズ #
systemdサービスファイルは、/usr/lib/systemd/system
にあります。サービスファイルをカスタマイズする場合は、次の手順に従います。
変更対象のファイルを
/usr/lib/systemd/system
から/etc/systemd/system
にコピーします。ファイル名は、元の名前のまま残します。/etc/systemd/system
のコピーを適宜変更します。設定変更の概要を表示するには、
systemd-delta
コマンドを使用します。このコマンドを使用すると、他の設定ファイルを上書きする設定ファイルを特定したり、複数の設定ファイルを比較対照することができます。詳細については、systemd-delta
マニュアルページを参照してください。
ファイル名が同じ場合、/etc/systemd
にある変更済みファイルが、/usr/lib/systemd/system
にある元のファイルよりも優先的に使用されます。
13.5.2 「ドロップイン」ファイルの作成 #
設定ファイルに何行かを追加したり、設定ファイルのごく一部を変更するには、「ドロップイン」と呼ばれるファイルを使用します。ドロップインファイルを使用すると、ユニットファイルの設定を拡張できます。その際に、ユニットファイル自体は編集も上書きもされません。
たとえば、/usr/lib/systemd/system/FOOBAR.SERVICE
にあるFOOBARサービスの1つの値を変更するには、次の手順に従います。
/etc/systemd/system/MY_SERVICE.service.d/
というディレクトリを作成します。.d
サフィックスが付いていることに注意してください。それ以外の点では、このディレクトリは、ドロップインファイルでパッチ適用するサービスと同じ名前になります。ディレクトリ内に、
WHATEVERMODIFICATION.conf
ファイルを作成します。このファイルには、変更する値が設定されている行のみを含めます。
ファイルに変更内容を保存します。このファイルは、元のファイルへの拡張として使用されます。
13.5.3 カスタムターゲットの作成 #
System V init SUSEシステムでは、管理者が独自のランレベル設定を作成できるように、ランレベル4は使用されていません。systemdでは、任意の数のカスタムターゲットを作成できます。ターゲットの作成は、graphical.target
などの既存のターゲットを改変することから始めることをお勧めします。
設定ファイル
/usr/lib/systemd/system/graphical.target
を/etc/systemd/system/MY_TARGET.target
にコピーして、必要に応じて修正してください。前のステップでコピーした設定ファイルは、すでにターゲットの必須な(「ハード」)依存関係を構築した状態になっています。希望する(「ソフト」)依存関係も構築するには、
/etc/systemd/system/MY_TARGET.target.wants
ディレクトリを作成します。希望するサービスごとに、
/usr/lib/systemd/system
から/etc/systemd/system/MY_TARGET.target.wants
へのシンボリックリンクを作成します。ターゲットの設定が完了したら、新しいターゲットを利用できるようにするために、systemdの設定を再ロードします。
systemctl daemon-reload
13.6 高度な使用方法 #
次のセクションでは、システム管理者向けの高度なトピックについて説明します。さらに高度なsystemdのドキュメントについては、Lennart Pöttering氏によるsystemdの資料(http://0pointer.de/blog/projects)を参照してください。
13.6.1 一時ディレクトリの消去 #
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のステータスを取得するには、以下のようにします。
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 2014-09-09 15:30:36 CEST; 1 weeks 6 days ago Docs: man:tmpfiles.d(5) man:systemd-tmpfiles(8) Sep 09 15:30:36 jupiter systemd[1]: Starting Daily Cleanup of Temporary Directories. Sep 09 15:30:36 jupiter systemd[1]: Started Daily Cleanup of Temporary Directories.
一時ファイルの処理について詳しくは、man 5 tmpfiles.d
を参照してください。
13.6.2 システムログ #
13.6.9項 「サービスのデバッグ」には、特定のサービスに対するログメッセージを閲覧する方法が説明されていますが、表示されるログメッセージは、サービスログからのものだけであるとは限りません。systemd
が記録したすべてのログメッセージ(「ジャーナル」と呼ばれる)にアクセスして問い合わせることもできます。最も古いログから始めて、すべてのログメッセージを表示するには、journalctl
コマンドを使用します。フィルタの適用や出力形式の変更については、man 1 journalctl
を参照してください。
13.6.3 スナップショット #
systemd
の現在の状態を名前付きのスナップショットに保存し、後でisolate
サブコマンドを使用してその状態に戻ることができます。定義した状態にいつでも戻ることができるため、サービスやカスタムターゲットをテストする際に便利です。スナップショットは現在のセッションでのみ使用可能で、システムを再起動すると自動的に削除されます。スナップショットの名前は、.snapshot
で終わる必要があります。
- スナップショットの作成
systemctl snapshot MY_SNAPSHOT.snapshot
- スナップショットの削除
systemctl delete MY_SNAPSHOT.snapshot
- スナップショットの表示
systemctl show MY_SNAPSHOT.snapshot
- スナップショットの有効化
systemctl isolate MY_SNAPSHOT.snapshot
13.6.4 カーネルモジュールのロード #
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)
のマニュアルページを参照してください。
13.6.5 サービスのロード前にアクションを実行 #
System Vでは、サービスをロードする前に実行する必要のあるinitアクションは、/etc/init.d/before.local
に指定する必要がありました。この手順は、systemdではサポートされません。サービスの起動前にアクションを実行する必要がある場合、以下のようにしてください。
- カーネルモジュールのロード
ドロップインファイルを
/etc/modules-load.d
ディレクトリに作成します(構文は、man modules-load.d
を参照)。- ファイルまたはディレクトリの作成、ディレクトリの消去、所有権の変更
ドロップインファイルを
/etc/tmpfiles.d
に作成します(構文は、man tmpfiles.d
を参照)。- その他のタスク
システムサービス(
/etc/systemd/system/before.service
など)を、次のテンプレートから作成します。[Unit] Before=NAME OF THE SERVICE YOU WANT THIS SERVICE TO BE STARTED BEFORE [Service] Type=oneshot RemainAfterExit=true ExecStart=YOUR_COMMAND # beware, executable is run directly, not through a shell, check the man pages # systemd.service and systemd.unit for full syntax [Install] # target in which to start the service WantedBy=multi-user.target #WantedBy=graphical.target
サービスファイルを作成したら、次のコマンドを実行する必要があります(
root
ユーザとして実行)。systemctl daemon-reload systemctl enable before
サービスファイルを変更するたびに、以下を実行する必要があります。
systemctl daemon-reload
13.6.6 カーネルのコントロールグループ(cgroup) #
従来の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
├─ntpd.service
│ └─1328 /usr/sbin/ntpd -p /var/run/ntp/ntpd.pid -g -u ntp:ntp -c /etc/ntp.conf
├─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 9, Kernel Control Groupsを参照してください。
13.6.7 サービスの終了(シグナルの送信) #
13.6.6項 「カーネルのコントロールグループ(cgroup)」で説明したとおり、System V initのシステムでは、プロセスをその親サービスプロセスに割り当てることができないことがあります。そのため、サービスとそのすべての子プロセスを終了するのが難しくなります。終了されていない子プロセスは、ゾンビプロセスとして残ってしまいます。
各サービスをcgroupに範囲制約するという、systemdの概念を採用することで、サービスのすべての子プロセスを明確に判別し、それら各プロセスに対してシグナルを送信できます。サービスに対してシグナルを送信する場合は、systemctl kill
コマンドを使用します。使用可能なシグナルの一覧については、man 7 signals
を参照してください。
- サービスに対する
SIGTERM
の送信 SIGTERM
は、送信されるデフォルトのシグナルです。systemctl kill MY_SERVICE
- サービスに対するSIGNALの送信
-s
オプションを使用することで、送信するシグナルを指定できます。systemctl kill -s SIGNAL MY_SERVICE
- プロセスの選択
デフォルトでは、
kill
コマンドは、指定したcgroup内のall
(すべての)プロセスに対してシグナルを送信します。control
(制御)またはmain
(メイン)のプロセスに対してだけ送信することもできます。限定されたプロセスに対する送信は、SIGHUP
を送信して設定を再ロードさせるような場合に有効です。systemctl kill -s SIGHUP --kill-who=main MY_SERVICE
13.6.8 D-Busサービスに関する重要な注意事項 #
D-Busサービスは、systemdクライアントと、pid 1として実行されるsystemdマネージャ間の通信用のメッセージバスです。dbus
はスタンドアロンのデーモンですが、初期化インフラストラクチャの不可欠な要素です。
動作中のシステムでdbus
を終了または再起動することは、pid 1の終了または再起動と同様の結果をもたらします。systemdのクライアント/サーバ通信が切断され、systemdのほとんどの機能が使用できなくなります。
したがって、dbus
の終了または再起動は推奨されず、サポートもされません。
dbus
またはdbus
に関連するパッケージを更新するには、再起動する必要があります。再起動が必要かどうか疑問に思う場合は、sudo zypper ps -s
コマンドを実行します。dbus
が一覧表示されているサービスに表示される場合は、システムを再起動する必要があります。
自動更新が再起動が必要なパッケージをスキップするように設定されている場合でも、dbus
は更新されることに留意してください。
13.6.9 サービスのデバッグ #
デフォルトでは、systemdは過剰に冗長な出力を行いません。サービスの起動が成功した場合は何も出力されず、失敗した場合は短いエラーメッセージが表示されます。サービスの起動や操作をデバッグする場合は、systemctl status
コマンドを使用してください。
systemdは、独自のログ機構(「ジャーナル」)でシステムメッセージを記録します。これにより、サービスメッセージとステータスメッセージを両方とも表示できます。status
コマンドはtail
コマンドに似た動作をするほか、ログメッセージをさまざまな形式で表示することもできます。これにより、強力なデバッグツールとして利用できるようになっています。
- サービスの起動失敗の表示
サービスの起動に失敗した場合は、
systemctl status MY_SERVICE
を実行することで、詳細なエラーメッセージを表示することができます。root #
systemctl start apache2 Job failed. See system journal and 'systemctl status' for details.root #
systemctl status apache2 Loaded: loaded (/usr/lib/systemd/system/apache2.service; disabled) Active: failed (Result: exit-code) since Mon, 04 Jun 2012 16:52:26 +0200; 29s ago Process: 3088 ExecStart=/usr/sbin/start_apache2 -D SYSTEMD -k start (code=exited, status=1/FAILURE) CGroup: name=systemd:/system/apache2.service Jun 04 16:52:26 g144 start_apache2[3088]: httpd2-prefork: Syntax error on line 205 of /etc/apache2/httpd.conf: Syntax error on li...alHost>- 直近N件のサービスメッセージ
status
サブコマンドは、デフォルトではサービスが出力した直近の10件のメッセージを表示します。表示するメッセージの件数を変更したい場合は、--lines=N
パラメータを使用して実行してください。systemctl status ntp systemctl --lines=20 status ntp
- 追記モードによるサービスメッセージの表示
サービスメッセージを「リアルタイムに」表示するには、
--follow
オプションを使用します。このオプションは、tail
-f
に似た動作をします。systemctl --follow status ntp
- メッセージの出力形式
--output=MODE
パラメータを指定すると、サービスメッセージの出力形式を変更できます。最も重要なモードには次のものがあります。short
デフォルトの形式。ログメッセージを、人間が読みやすいタイムスタンプと併記して表示します。
verbose
すべての項目を表示する完全な出力。
cat
タイムスタンプを併記しない、簡潔な出力。
13.7 詳細情報 #
systemdの詳細については、次のオンラインリソースを参照してください。
- ホームページ
- systemd (管理者向け)
systemdの著者のうちの1人、Lennart Pöttering氏によるブログに、systemdに関する複数の投稿があります(本章記述時点では13個の投稿)。それらは、次のサイトに記載されています。http://0pointer.de/blog/projects