15 systemdデーモン #

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

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

systemdユニットファイルの詳細については、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.4項 「カスタムターゲットの作成」を参照してください。

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スクリプトで起動されたサービスも終了します。このエラーを回避するには、次の手順に従います。

ユニットファイルをカスタマイズするための推奨される方法は、systemctl edit SERVICEコマンドを使用する方法です。このコマンドはデフォルトのテキストエディタを起動し、/etc/systemd/system/NAME.service.d/にあるoverride.confファイルを使用してディレクトリを作成します。また、このコマンドは、実行中のsystemdプロセスに変更について通知するようにします。

または、systemctl edit --full SERVICEを実行して、空のファイルの代わりに元のファイルのコピーを開いて編集することもできます。ファイルを編集する際には、既存のセクションを削除しないようにしてください。

演習として、システムがMariaDBの起動を待機する時間を変更します。rootとして、systemctl edit --full mariadb.serviceを実行します。開かれたファイルは次のように表示されます。

[Unit]
Description=MySQL server
Wants=basic.target
Conflicts=mariadb.target
After=basic.target network.target

[Install]
WantedBy=multi-user.target
Alias=mysql.service

[Service]
Restart=on-abort
Type=notify
ExecStartPre=/usr/lib/mysql/mysql-systemd-helper  install
ExecStartPre=/usr/lib/mysql/mysql-systemd-helper  upgrade
ExecStart=/usr/lib/mysql/mysql-systemd-helper     start

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

# Prevent writes to /usr, /boot, and /etc
ProtectSystem=full

# Prevent accessing /home, /root and /run/user
ProtectHome=true

UMask=007

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

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

環境設定ファイルのマイナーな変更については、いわゆるドロップインファイルを使用します。ドロップインファイルを使用すると、ユニットファイルの設定を拡張できます。その際に、ユニットファイル自体は編集も上書きもされません。

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

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

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

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

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

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

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

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

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

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

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

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

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

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
}

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

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

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

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

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

すべてのタイマユニットには、それが制御する対応する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は、タイマが最後の開始時刻を逃した場合(たとえば、システムの電源がオフになっているため)、タイマが有効化された直後にサービスがトリガされることを示します。

オプションOnCalendaranを使用して、次の形式で、サービスをトリガするための特定の日時を定義することもできます: 。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/ ディレクトリに保存します。作成したユニットファイルが正しいかどうかを確認するには、次のコマンドを実行します。

tux > 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を実行します。