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とは異なり、次のようにコマンドを実行します。

systemctl start <my_1st_service>.service <my_2nd_service>.service

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

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

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

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

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

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

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

作業	systemdコマンド	System V initコマンド
有効化.	systemctl enable <my_service(s)>.service	insserv <my_service(s)>
無効化.	systemctl disable <my_service(s)>.service	insserv -r <my_service(s)>
確認.  サービスが有効になっているかどうかを示します。	systemctl is-enabled <my_service>.service	該当なし
再有効化.  サービスの再起動と同様に、このコマンドはいったんサービスを無効化した後に有効化します。サービスにデフォルト値を設定して再有効化する場合に利用します。	systemctl reenable <my_service>.service	該当なし
マスク.  サービスを「無効化」しても、手動で起動できてしまいます。サービスを完全に無効化するには、マスクを設定する必要があります。 注意してご使用ください。	systemctl mask <my_service>.service	該当なし
マスク解除.  マスクを設定したサービスは、マスクを解除しないと使用できません。	systemctl unmask <my_service>.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では、この設定が使用されることはありません。独自のブート可能なターゲットを作成する方法については、11.5.3項 「カスタムターゲットの作成」を参照してください。

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

root # systemctl
UNIT                                LOAD   ACTIVE SUB       JOB DESCRIPTION
[...]
systemd-random-seed-load.path       loaded active waiting       Random Seed
acpid.service                       loaded active running       ACPI Event Daemon
apache2.service                     loaded failed failed        apache
avahi-daemon.service                loaded active running       Avahi mDNS/DNS-SD Stack
bluez-coldplug.service              loaded active exited        LSB: handles udev coldplug of bluetooth dongles
console-kit...-system-start.service loaded active exited        Console System Startup Logging
cron.service                        loaded active running       Command Scheduler
cups.service                        loaded active running       CUPS Printing 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.
JOB    = Pending job for the unit.

107 units listed. Pass --all to see inactive units, too.

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

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にある元のファイルよりも優先的に使用されます。

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

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

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

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

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

systemdにより、次の場所にある環境設定ファイルを使用してブート時に自動的にカーネルモジュールをロードできます。

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

従来の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 8, Kernel Control Groups, System Analysis and Tuning Guideを参照してください。

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

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

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

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