サービスを管理するためのサブコマンドは、 System V init でのサービス管理 コマンドと同じ (start, stop, ...) です。一般的な使い方は下記のとおりです:

systemd では、複数のサービスを一括で管理することもできます。 init スクリプト をそれぞれ実行しなければならなかった System V init とは異なり、下記のように 実行します:

systemctl start <1 つめのサービス>.service <2 つめのサービス>.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 は過剰に冗長な出力を行ないません。サービスの起動が 成功した場合は何も出力されず、失敗した場合にのみ短いエラーメッセージを 表示します。起動についてデバッグしたり、サービスの操作状態を確認したり したい場合は、 systemctl status コマンドをお使いください。

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

上述のサービスの管理コマンドでは、現在動作中のシステムに対するサービスの 操作を行ないます。 systemd では、サービスを恒久的に有効化／無効化し、 必要に応じてシステムの起動時に自動的に開始したり、逆に開始しないように したりすることもできます。これは YaST やコマンドラインからも実施すること ができます。

8.1.3.1. コマンドラインからのサービスの有効化／無効化¶

下記の表には、 systemd と System V init におけるサービスの有効化／無効化 コマンドを示しています:

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

表8.2 サービスの有効化／無効化のコマンド

作業	systemd でのサブコマンド	SysV init でのサブコマンド
有効化	systemctl enable <サービス名>.service	insserv <サービス名>
無効化	systemctl disable <サービス名>.service	insserv -r <サービス名>
確認 サービスが有効に設定されているかどうかを表示します。	systemctl is-enabled <サービス名>.service	n/a
再有効化 サービスを再起動するのと似た仕組みで、このコマンドは いったん無効化した後に有効化します。これはサービスの有効化状態を、 既定値に戻したい場合に利用します。	systemctl reenable <サービス名>.service	n/a
マスク サービスを 「無効化」 しても、コマンドラインから 実行することでサービスは起動できてしまいます。サービスを完全に 無効化するには、このようにマスクを設定する必要があります。 注意してお使いください。	systemctl mask <サービス名>.service	n/a
マスク解除 マスクを行なった場合は、マスクを解除することで 再度起動できるようになります。	systemctl unmask <サービス名>.service	n/a

8.1.3.2. YaST を利用したサービスの有効化／無効化¶

YaST のモジュールを YaST+システム+システムサービス (ランレベル) で起動すると、まずは 簡易モード で表示されます。これは 利用可能な全てのサービスに対して、概要と状態 (詳しくは 図8.1「システムサービス (ランレベル)」 をご覧ください) が表示されるだけの ものです。左側の列にはサービスの名前が、中央の列にはサービスの状態が、右側の列 には短い説明が表示されます。サービスを選択すると、下側により詳しい説明が表示 されます。サービスを有効化するには、表から対象のサービスを選択して 有効にする を選択してください。サービスを無効化する場合も 同様です。

熟練者モード は、ランレベル (詳しくは 8.2.1項 「ターゲットとランレベル」 をお読みください) を詳細に制御する ために使用するモードです。現在の既定のランレベルは、画面上部に表示されます。 通常、 openSUSE システムにおける既定のランレベルは 5 (ネットワークと X Window System を動作させるマルチユーザ環境) です。場合によっては ランレベル 3 (ネットワークを動作させるマルチユーザ環境) が設定されている 場合もあります。

ウインドウ内の表を利用することで、 個別のサービスやデーモンを有効化したり無効化したりすることもできます。 表内には利用可能なサービスやデーモンの一覧が表示され、お使いのシステムで 現在有効化されているかどうかと、どのランレベルに対して有効に設定されて いるかどうかが表示されます。マウスでいずれかの行 (サービスやデーモン) を 選択したあと、ランレベルを表すチェックボックスで設定を行ってください。 また、現在選択されているサービスやデーモンについて、概要説明が表の下に 表示されます。

	ランレベル設定の誤りによって発生する障害について
ランレベルの設定を誤ると、場合によってはお使いのシステムが利用できなく なってしまいます。設定を適用する前に、どのような影響があるのかを ご確認ください。

図8.1 システムサービス (ランレベル)¶

開始／中止／更新 を押すと、サービスを開始したり停止 したりすることができます。 状態を更新 を押すと、現在の 状態を表示することができます。また、 セット／リセット を押すと、行なった変更をシステムに適用したり、ランレベルエディタを起動する 前の設定に戻したりすることができます。 OK を押すと、 変更点をディスクに書き込みます。

System V init の環境では、システムは 「ランレベル」 と呼ばれる 仕組みを利用して起動していました。ランレベルとは、システムやサービスの起動 方法を定義するもので、それぞれ番号を付けて区別していました。よく知られて いるランレベルとしては、 0 (システムのシャットダウン), 3 (ネットワークまでを動作させるマルチユーザ環境), 5 (ネットワークとディスプレイマネージャを動作させる マルチユーザ環境) などがあります。

systemd では、 「ターゲットユニット」 と呼ばれる新しい仕組みを 利用しています (もちろん従来のランレベルの考え方についても、完全な互換性を 備えています) 。ターゲットユニットは、番号ではなく名前で識別する仕組みで、 それぞれ異なる目的を示しています。たとえば local-fs.target や swap.target は、それぞれローカルの ファイルシステムのマウント、スワップ領域のマウントなどを表わします。

graphical.target というターゲットは、ネットワークと ディスプレイマネージャを動作させるマルチユーザ環境で、ランレベル 5 と同じ意味を 持っています。このようなターゲットは 「メタ」 ターゲットと呼ばれるもので、他のターゲットをまとめてセットにしたものを 指しています。このように、 systemd は既存のターゲットを組み合わせる ことで、簡単に独自のターゲットを作成できるため、非常に柔軟な運用を行なう ことができます。

下記の表では、 systemd で利用される最も重要なターゲットを示しています。 全てを網羅した表については、 man 7 systemd.special で表示 されるマニュアルページをお読みください。

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

	systemd における /etc/inittab の有効性について
SysV init のシステムにおけるランレベル管理は /etc/inittab で設定しますが、 systemd では、このファイルに書かれた設定を読み込むことは ありません 。独自のターゲットを作成する方法に ついては、 8.2.2項 「独自のターゲット」 をお読みください。

System V init による SUSE システムでは、ランレベル 4 を利用で独自のランレベル 設定を構築できるようになっていました。 systemd では、独自のターゲットを作成 することで、任意の数だけ独自の設定を構築することができます。なお、独自の ターゲットを構築する場合は、 graphical.target など 既存のターゲットに追加する形で構築することをお勧めします。

	カスタマイズ作業時の注意
systemd のカスタマイズは /etc/systemd ディレクトリ内で 行ない、 /lib/systemd 内では 決して 実施しないでください。後者のディレクトリ内でカスタマイズを行なっても、次回の systemd の更新の際、変更点が上書きされてしまい、元に戻ってしまいます。

systemd には、システムの起動処理を分析できる機能が用意されています。 この機能により、全てのサービスに対する状態を (/var/log を確認する 方法よりは) 便利に確認することができます。また systemd では、起動処理を 調査して、サービスの起動にかかっている時間を調べることもできます。

jupiter.example.com: ~ # 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.

jupiter.example.com: ~ # 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 | less

8.1.2項 「サービスのデバッグ」 では、それぞれの サービスに対してログを閲覧するための方法を示してきましたが、ログメッセージは サービスからのものだけであるとは限りません。 systemd が記録した全てのログ メッセージ (「ジャーナル」 と呼びます) に対するアクセス方法も用意 されています。最も古いログから始まる、全てのログを表示するには、 systemd-journalctl コマンドをお使いください。なお、 フィルタの適用や出力形式の変更について、詳しくは man 1 systemd-journalctl で表示されるマニュアルページをお読みください。

systemd には、現在の状態を名前付きのスナップショットと して保存し、後から isolate サブコマンドでその状態に戻す機能が 用意されています。これは元に戻すことができることから、サービスや独自のターゲットの テストに便利な仕組みです。なお、スナップショットは現在のセッションに対してのみ有効で、 システムを再起動すると自動的に削除されます。また、スナップショットの名前は .snapshot で終わるものでなければなりません。

従来の SysV init システムでは、起動されるサービスに対して、明確なプロセス 設定を行なうことができませんでした。 Apache などのように、サードパーティ製の プロセス (CGI や Java のプロセス) を多数起動し、サードパーティ製のプロセス 自身もプロセスを生成するようなシステムの場合は、プロセスに対する制御を 明示的に行なうことが難しい場合があるほか、場合によっては不可能であることも あります。またそれに加えて、子プロセスを残したまま終了してしまい、結果として サービスが正しく終了しないことも考えられます。

systemd では、そのような問題を cgroups を利用することで解決しています。 cgroups はプロセスをまとめて管理するためのカーネルの機能で、全ての子プロセスを 階層構造で管理します。 systemd では、サービスに対して別々の cgroup を 設定します。非特権プロセスでは cgroup を変えることができないため、サービス から起動したプロセスがどれなのかを、簡単に判別できるようになる、という仕組みです。

サービスに属する全てのプロセスを表示するには、 systemd-cgls コマンドを使用します。実行すると、下記のように (一部省略しています) 表示されます:

~ # systemd-cgls --no-pager
├ user
│ └ root
│   └ 1
│     ├ 2279 sshd: root@pts/0
│     ├ 2282 -bash
│     └ 2541 systemd-cgls --no-pager
└ system
  ├ 1 /sbin/init splash showopts
  ├ apache2.service
  │ ├ 2535 /usr/sbin/httpd2-prefork -f /etc/apache2/httpd.conf -D SYSTEMD -k start
  │ ├ 2536 /usr/sbin/httpd2-prefork -f /etc/apache2/httpd.conf -D SYSTEMD -k start
  │ ├ 2537 /usr/sbin/httpd2-prefork -f /etc/apache2/httpd.conf -D SYSTEMD -k start
  │ ├ 2538 /usr/sbin/httpd2-prefork -f /etc/apache2/httpd.conf -D SYSTEMD -k start
  │ ├ 2539 /usr/sbin/httpd2-prefork -f /etc/apache2/httpd.conf -D SYSTEMD -k start
  │ └ 2540 /usr/sbin/httpd2-prefork -f /etc/apache2/httpd.conf -D SYSTEMD -k start
  ├ xdm.service
  │ ├ 2250 /usr/bin/xdm
  │ ├ 2253 /usr/bin/X -nolisten tcp -br vt7 -auth /var/lib/xdm/authdir/authfiles/A:0-ii8Goo
  │ ├ 2263 -:0         
  │ └ 2276 /usr/bin/xconsole -notify -nostdin -verbose -exitOnFail
  ├ ntp.service
  │ └ 2202 /usr/sbin/ntpd -p /var/run/ntp/ntpd.pid -g -u ntp:ntp -c /etc/ntp.conf
  ├ sshd.service
  │ └ 1743 /usr/sbin/sshd -D
    

cgroups について、詳しくは 第10章 カーネルのコントロールグループ (↑システム分析とチューニングガイド) をお読みください。

8.3.3項 「カーネルのコントロールグループ (cgroups)」 で説明したとおり、 SysV init のシステムでは親プロセスを判断することが不可能になってしまうことがありました。 このような状態になってしまうと、サービスから起動された多数のプロセスがわからなく なってしまい、子プロセスはゾンビプロセスとして残ってしまいます。

systemd の cgroups 管理の仕組みにより、サービスから起動された子プロセスを 容易に判別し、それらに対してまとめてシグナルを送信することができます。 サービスに対してシグナルを送信する場合は、 systemctl kill コマンドをお使いください。利用可能なシグナルの一覧は、 man 7 signals コマンドで表示することができます。