目次にジャンプページナビゲーションにジャンプ: 前のページ[アクセスキーp]/次のページ[アクセスキーn]
documentation.suse.com / SUSE Linux Enterprise Desktopドキュメント / 管理ガイド / Linuxシステムのブート / systemdデーモン
適用項目 SUSE Linux Enterprise Desktop 15 SP6

19 systemdデーモン

systemdは、システムを初期化します。このプロセスのIDは1です。systemdはカーネルによって直接起動され、通常はプロセスを強制終了するシグナル9が使えないようにします。他のすべてのプログラムは、systemdまたは子プロセスのいずれかによって直接起動されます。systemdは、System V initデーモンの後継であり、(initスクリプトのサポートにより)System V initと完全に互換性があります。

systemdの主な利点は、サービスの開始を並列化することによりブート時間を大幅に短縮できることです。さらに、systemdは、サービスが必要なときだけ起動します。デーモンは、ブート時に無条件で起動されることはなく、最初に必要になったときに起動されます。systemdは、カーネルコントロールグループ(cgroups)、スナップショットの作成、システム状態の復元もサポートしています。詳細については、https://www.freedesktop.org/wiki/Software/systemd/を参照してください。

ヒント
ヒント: WSL内のsystemd

Windows Subsystem for Linux (WSL)を使用すると、Microsoft WindowsオペレーティングシステムでLinuxアプリケーションおよびディストリビューションを実行できるようになります。WSLは、systemdの代わりに、initプロセスを使用します。WSLで実行中のSLEDsystemdを有効にするには、プロセスを自動化するwsl_systemdパターンをインストールします。

> sudo zypper in -t pattern wsl_systemd

または、/etc/wsl.confを編集して、次の行を手動で追加することもできます。

[boot]
systemd=true

WSLでのsystemdのサポートは部分的であり、systemdユニットファイルには、合理的なプロセス管理動作が必要であることに注意してください。

19.1 systemdの概念

次のセクションでは、systemdの背後にある概念について説明します。

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

  • 並列化機能

  • ソケットやD-Busアクティベーションによるサービスの起動

  • デーモンのオンデマンド起動

  • Linux cgroupsを使用したプロセスの追跡

  • システム状態のスナップショットの作成、およびその状態への復元

  • マウントポイントと自動マウントポイントの保持

  • 精巧なトランザクションの依存関係に基づくサービス制御ロジックの実装

19.1.1 ユニットファイル

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

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

  • サービス.  プロセスに関する情報(たとえば、実行中のデーモン)。サービスファイルは.serviceで終わります。

  • ターゲット.  システム起動時のユニットのグループ化に、または同期ポイントとして使用されます。ターゲットファイルは.targetで終わります。

  • ソケット.  ソケットに基づくアクティベーション(inetdなど)でのIPC、ネットワークソケット、ファイルシステムFIFOに関する情報。ソケットファイルは.socketで終わります。

  • パス.  その他のユニットをトリガするために使用されます(たとえば、ファイル変更時のサービスの実行など)。パスファイルは.pathで終わります。

  • タイマ.  タイマ制御された、タイマに基づくアクティベーションに関する情報。タイマファイルは.timerで終わります。

  • マウントポイント.  通常はfstabジェネレータによって自動生成されます。マウントポイントファイルは.mountで終わります。

  • 自動マウントポイント.  ファイルシステムの自動マウントポイントに関する情報。自動マウントポイントファイルは.automountで終わります。

  • スワップ.  スワップデバイスに関する情報またはメモリページング用のファイル。スワップファイルは.swapで終わります。

  • デバイス.  sysfs/udev(7)デバイスツリーに公開されているデバイスユニットに関する情報。デバイスファイルは.deviceで終わります。

  • スコープ/スライス.  プロセスグループのリソースを階層管理する際の概念。スコープ/スライスファイルは.scope/.sliceで終わります。

systemdユニットファイルの詳細については、https://www.freedesktop.org/software/systemd/man/latest/systemd.unit.htmlを参照してください。

19.2 基本的な使用方法

System V initシステムでは、initスクリプト、insservtelinitなどの複数のコマンドを使用してサービスを処理します。systemdでは、ほとんどのサービス関連のタスクを処理するコマンドが1つだけ(systemctl)なので、サービスの管理が容易に行えます。gitzypperのように、コマンドの後ろにサブコマンドを指定して実行します。

systemctl GENERAL OPTIONS SUBCOMMAND SUBCOMMAND OPTIONS

完全なマニュアルについては、man 1 systemctlを参照してください。

ヒント
ヒント: 端末の出力とbashの補完

systemdのコマンドは、出力先が端末である場合(パイプやファイルなどではない場合)、デフォルトではページャに長い出力が送信されます。ページングモードをオフにするには、--no-pagerオプションを使用してください。

systemdでは、bashによる補完もサポートしています。サブコマンドの最初の1文字を入力し、<Tab>を押すことで実行できます。この機能は、bashシェルを利用している場合にのみ使用できるもので、bash-completionパッケージをインストールしておく必要があります。

19.2.1 稼働中のシステムでのサービスの管理

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

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

> sudo systemctl start MY_1ST_SERVICE MY_2ND_SERVICE

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

> sudo systemctl list-unit-files --type=service

次の表に、systemdとSystem V initの最も重要なサービス管理コマンドを示します。

表 19.1: サービス管理コマンド

タスク

systemd コマンド

System V initコマンド

起動. 

start
start

停止. 

stop
stop

再起動.  サービスを停止し、後で起動します。サービスがまだ起動していない場合は、そのサービスを起動します。

restart
restart

条件付きの再起動.  サービスが現在実行中の場合、サービスを再起動します。実行されていないサービスについては、何も行いません。

try-restart
try-restart

再ロード.  サービスに対し、操作を中断せずに設定ファイルを再ロードするように指示します。Apacheに、変更後のhttpd.conf設定ファイルを再ロードさせる、などの使用方法をします。一部のサービスは再ロードをサポートしていません。

reload
reload

再ロードまたは再起動.  サービスが再ロードをサポートしていれば再ロードし、サポートしていなければ再起動します。サービスがまだ起動していない場合は、そのサービスを起動します。

reload-or-restart
n/a

条件付きの再ロードまたは再起動.  サービスが再ロードをサポートしていれば再ロードし、サポートしていなければ再起動します(現在実行中の場合)。実行されていないサービスについては、何も行いません。

reload-or-try-restart
n/a

詳細なステータス情報の取得.  サービスのステータスについて、情報を表示します。systemdコマンドでは、説明、実行可能ファイル、ステータス、cgroupのほか、直近でサービスが出力したメッセージ(19.6.9項 「サービスのデバッグ」を参照)が表示されます。System V initで表示される詳細のレベルは、サービスごとに異なります。

status
status

簡潔なステータス情報の取得.  サービスがアクティブかどうかを示します。

is-active
status

19.2.2 サービスの恒久的な有効化/無効化

上述のサービス管理コマンドでは、現在のセッションに対するサービスを操作できます。systemdでは、サービスを恒久的に有効化/無効化して、必要に応じて自動的に起動したり、常に使用不可にすることもできます。この作業は、YaSTまたはコマンドラインを使用して実行できます。

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

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

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

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

表 19.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

該当なし

19.3 システムの起動とターゲットの管理

システムを起動し、シャットダウンするプロセス全体は、systemdによって管理されます。この点から見ると、カーネルは、他のプログラムからの要求に従って、他のすべてのプロセスを管理し、CPU時間とハードウェアアクセスを調整するバックグラウンドプロセスと考えることができます。

19.3.1 ターゲットとランレベルの比較

System V initでは、システムはランレベルと呼ばれる状態でブートしていました。ランレベルはシステムの起動方法および稼働中のシステムで使用可能なサービスを定義します。ランレベルは番号付けされています。よく知られているランレベルは、0 (システムのシャットダウン)、3 (ネットワークを使用するマルチユーザシステム)、および5 (ネットワークとディスプレイマネージャを使用するマルチユーザシステム)です。

systemdでは、ターゲットユニットと呼ばれる仕組みを使用する新しい概念が導入されています。ただし、ランレベルの概念とも、完全な互換性を維持しています。ターゲットユニットには、番号ではなく名前が付けられており、特定の目的を果たします。たとえば、ターゲットlocal-fs.targetswap.targetは、それぞれローカルファイルシステムのマウントと、スワップ領域のマウントを実行します。

ターゲットgraphical.targetは、ネットワーク機能とディスプレイマネージャ機能を使用するマルチユーザシステムで、ランレベル5に相当します。graphical.targetなどの複合ターゲットは、他のターゲットのサブセットを組み合わせることで、メタターゲットとして機能します。systemdでは、既存のターゲットを組み合わせることで簡単にカスタムターゲットを作成できるため、非常に柔軟な運用が実現されます。

次のリストは、systemdの最も重要なターゲットユニットを示しています。すべてを網羅したリストについては、man 7 systemd.specialを参照してください。

systemdで選択できるターゲットユニット
default.target

デフォルトで起動されるターゲット。実在するターゲットというよりは、別のターゲット(graphic.targetなど)に対するシンボリックリンクであるといえます。YaSTを介して恒久的に変更できます(19.4項 「YaSTを使用したサービスの管理」を参照)。セッション用に変更する場合は、ブートプロンプトで、カーネルパラメータsystemd.unit=MY_TARGET.targetを使用してください。

emergency.target

コンソール上で最小限の緊急rootシェルを起動します。ブートプロンプトでのみ、systemd.unit=emergency.targetと指定して使用します。

graphical.target

ネットワークとマルチユーザをサポートし、ディスプレイマネージャを使用するシステムを起動します。

halt.target

システムをシャットダウンします。

mail-transfer-agent.target

メールの送受信に必要なすべてのサービスを起動します。

multi-user.target

ネットワークに対応したマルチユーザシステムを起動します。

reboot.target

システムを再起動します。

rescue.target

ネットワークに対応しないシングルユーザrootセッションを起動します。システム管理のための基本ツールが用意されています。rescueターゲットは、ログインの失敗やディスプレイドライバでの問題の解決など、複数のシステムの問題を解決するのに適しています。

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

現在のターゲットを検査するには、systemctl get-defaultコマンドを使用します。

表 19.3: System Vのランレベルとsystemdのターゲットユニット

System Vランレベル

systemd ターゲット

用途

0

runlevel0.target, halt.target, poweroff.target

システムのシャットダウン

1、S

runlevel1.target, rescue.target,

シングルユーザモード

2

runlevel2.target, multi-user.target,

リモートネットワークなしのローカルマルチユーザ

3

runlevel3.target, multi-user.target,

ネットワークを使用するフルマルチユーザ

4

runlevel4.target

未使用/ユーザ定義

5

runlevel5.target, graphical.target,

ネットワークとディスプレイマネージャを使用するフルマルチユーザ

6

runlevel6.target, reboot.target,

システムの再起動

重要
重要: systemd/etc/inittabを無視する

System V initシステムのランレベルは、/etc/inittabで設定されています。systemdでは、この設定が使用されることはありません。独自のブート可能なターゲットを作成する方法については、19.5.5項 「カスタムターゲットの作成」を参照してください。

19.3.1.1 ターゲット変更用のコマンド

次のコマンドを使用して、ターゲットユニットを操作します。

タスク

systemd コマンド

System V initコマンド

現在のターゲット/ランレベルの変更

systemctl isolate MY_TARGET.ターゲット

telinit X

デフォルトのターゲット/ランレベルへの変更

systemctl default

該当なし

現在のターゲット/ランレベルの取得

systemctl list-units --type=target

systemdでは通常、複数のアクティブターゲットを利用します。そのため、このコマンドは現在アクティブなターゲットをすべて表示します。

who -r

あるいは、

runlevel

デフォルトのランレベルの恒久的な変更

サービスマネージャを使用するか、次のコマンドを実行します。

ln -sf /usr/lib/systemd/system/ MY_TARGET.target /etc/systemd/system/default.target

サービスマネージャを使用するか、次の行を変更します。

id: X:initdefault:

での /etc/inittab

現在のブートプロセスに対するデフォルトランレベルの変更

ブートプロンプトで次のオプションを入力します。

systemd.unit= MY_TARGET.ターゲット

ブートプロンプトで必要なランレベルの番号を入力します。

ターゲットやランレベルの依存関係の表示

systemctl show -p "Requires" MY_TARGET.ターゲット

systemctl show -p "Wants" MY_TARGET.ターゲット

Requiresを指定すると、ハード依存関係(必ず解決する必要がある依存関係)が表示されます。Wantsを指定すると、ソフト依存関係(可能であれば解決される依存関係)が表示されます。

該当なし

19.3.2 システム起動のデバッグ

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

19.3.2.1 サービスの起動の確認

システムのブート後に起動された全サービスのリストを確認するには、systemctlと入力します。次のように、すべてのアクティブなサービスが表示されます (一部省略しています)。特定のサービスの詳細情報が必要な場合は、systemctl status MY_SERVICEを使用してください。

例 19.1: アクティブなサービスの一覧表示
# 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'.

起動に失敗したサービスだけを表示する場合は、--failedオプションを指定してください。

例 19.2: 起動に失敗したサービスの一覧表示
# 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

[...]

19.3.2.2 起動時間のデバッグ

システムの起動時間をデバッグするために、systemdでは、systemd-analyzeコマンドが用意されています。このコマンドでは、全体の起動時間や起動時間順のサービス一覧を表示できるほか、他のサービスの起動時間と対比するために利用できる、SVG画像を生成することもできます。

システムの起動時間の一覧表示
# systemd-analyze
Startup finished in 2666ms (kernel) + 21961ms (userspace) = 24628ms
サービスの起動時間の一覧表示
# systemd-analyze blame
    15.000s backup-rpmdb.service
    14.879s mandb.service
     7.646s backup-sysconfig.service
     4.940s postfix.service
     4.921s logrotate.service
     4.640s libvirtd.service
     4.519s display-manager.service
     3.921s btrfsmaintenance-refresh.service
     3.466s lvm2-monitor.service
     2.774s plymouth-quit-wait.service
     2.591s firewalld.service
     2.137s initrd-switch-root.service
     1.954s ModemManager.service
     1.528s rsyslog.service
     1.378s apparmor.service
    [...]
サービスの起動時間を表す画像
# systemd-analyze plot > jupiter.example.com-startup.svg
Image

19.3.2.3 起動プロセス全体の確認

上記のコマンドは、起動されるサービスとその起動時間を一覧にします。より詳細な概要については、ブートプロンプトで次のパラメータを指定して、完全な起動手順の詳細なログを作成するようにsystemdに指示します。

systemd.log_level=debug systemd.log_target=kmsg

systemdが、ログメッセージをカーネルのリングバッファに書き込むようになります。バッファを閲覧するには、dmesgを使用してください。

> dmesg -T | less

19.3.3 System Vとの互換性

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

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

  1. 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

    UPPERCASE LETTERSで記述されている値はすべて適切な値に置き換えてください。

    1

    オプション: initスクリプトでデーモンを起動する場合にのみ使用してください。

    2

    multi-user.targetは、graphical.targetでブートしたときにinitスクリプトも起動します。ディスプレイマネージャでブートする場合にのみinitスクリプトを起動するときは、graphical.targetを使用します。

  2. systemctl start APPLICATIONコマンドで、デーモンを起動します。

19.4 YaSTを使用したサービスの管理

基本的なサービス管理は、YaSTサービスマネージャモジュールで行うこともできます。このモジュールは、サービスの起動、停止、有効化、および無効化をサポートしています。サービスのステータスを表示したり、デフォルトのターゲットを変更することもできます。YaST › システム › サービスマネージャの順に選択して、YaSTモジュールを起動します。

サービスマネージャ
図 19.1: サービスマネージャ
デフォルトのシステムターゲットの変更

システムのブート先になるターゲットを変更するには、デフォルトのシステムターゲットドロップダウンボックスからターゲットを選択します。最もよく使用されているターゲットは、グラフィカルインタフェース(グラフィカルなログイン画面を起動する)とマルチユーザ(コマンドラインモードでシステムを起動する)です。

サービスの起動または停止

テーブルからサービスを選択します。状態列は、現在サービスが実行されているかどうかを示します(アクティブか、アクティブでないかを示します)。ステータスを切り替えるには、起動または停止を選択します。

サービスを起動または停止すると、現在実行されているセッションのステータスが変更されます。再起動時にステータスを変更するには、サービスを有効化または無効化する必要があります。

サービスの起動動作の定義

サービスは起動時に自動的に起動することも、手動で起動することもできます。テーブルからサービスを選択します。起動列には、現在手動で起動されているか、起動時に起動されているかが表示されます。ステータスを切り替えるには、起動モードを選択します。

現在のセッションのサービスステータスを変更するには、先に記載されているように、起動または停止する必要があります。

ステータスメッセージの表示

サービスのステータスメッセージを表示するには、リストからサービスを選択し、詳細の表示を選択します。出力は、コマンドsystemctl -l status MY_SERVICEで生成されたものと同じです。

19.5 カスタマイズsystemd

以下のセクションでは、systemdユニットファイルのカスタマイズ方法を説明しています。

19.5.1 ユニットファイルはどこに保存されていますか?

SUSEによって提供されるsystemdユニットファイルは、/usr/lib/systemd/に保存されています。カスタマイズされたユニットファイルとユニットファイルの「ドロップイン」は、/etc/systemd/に保存されています。

警告
警告: カスタマイズが上書きされないようにする

systemdをカスタマイズする場合は、/usr/lib/systemd/ではなく、/etc/systemd/ディレクトリを必ず使用してください。そうしないと、systemdの次回の更新によって、変更内容が上書きされてしまいます。

19.5.2 ドロップインファイルによる上書き

ドロップインファイル(または「ドロップイン」)は、ユニットファイルの特定の設定のみを上書きする部分的なユニットファイルです。ドロップインは、メイン設定ファイルより優先されます。コマンドsystemctl edit SERVICEはデフォルトのテキストエディタを起動し、/etc/systemd/system/NAME.service.d/に空のoverride.confファイルを含むディレクトリを作成します。また、このコマンドは、実行中のsystemdプロセスに変更について通知するようにします。

たとえば、システムがMariaDBを起動するまで待機する時間を変更するには、sudo systemctl edit mariadb.serviceを実行し、開いたファイルを編集して、変更した行のみを含めます。

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

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

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

警告
警告: フルユニットファイルのコピーの作成

systemctl edit --full SERVICEコマンドで--fullオプションを使用すると、元のユニットファイルのコピーが作成され、特定のオプションを変更できます。SUSEでユニットファイルが更新されると、その変更は、/etc/systemd/system/ディレクトリのカスタマイズされたコピーによって上書きされるため、このようなカスタマイズはお勧めしません。さらに、SUSEがディストリビューションのドロップインに更新を提供する場合、--fullで作成されたユニットファイルのコピーが上書きされます。この混乱を回避し、常にカスタマイズを有効にするには、ドロップインを使用します。

19.5.3 ドロップインファイルを手動で作成する

systemctl editコマンドを使用するのとは別に、優先度をより細かく制御できるように、ドロップインを手動で作成できます。このようなドロップインを使用すると、ファイル自体を編集したり、上書きしたりせずに、ユニットとデーモン両方の設定ファイルを拡張できます。次のディレクトリに保存されます。

/etc/systemd/*.conf.d//etc/systemd/system/*.service.d/

システム管理者によって追加され、カスタマイズされたドロップイン。

/usr/lib/systemd/*.conf.d//usr/lib/systemd/system/*.service.d/

アップストリーム設定を上書きするために、カスタマイズパッケージによってインストールされたドロップイン。たとえば、SUSEにはsystemd-default-settingsが付属しています。

ヒント
ヒント

ユニット検索パスのフルリストについては、man 5 systemd.unitのマニュアルページを参照してください。

たとえば、systemd-journaldのデフォルト設定によって適用されるレート制限を無効にするには、次の手順に従います。

  1. /etc/systemd/journald.conf.dというディレクトリを作成します。

    > sudo mkdir /etc/systemd/journald.conf.d
    注記
    注記

    ディレクトリ名は、ドロップインファイルでパッチを適用するサービス名の後に付ける必要があります。

  2. そのディレクトリに、上書きするオプションを指定して/etc/systemd/journald.conf.d/60-rate-limit.confファイルを作成します。次に例を示します。

    > cat /etc/systemd/journald.conf.d/60-rate-limit.conf
    # Disable rate limiting
    RateLimitIntervalSec=0
  3. 変更を保存して、対応するsystemdデーモンのサービスを再起動します。

    > sudo systemctl restart systemd-journald
注記
注記: 名前の競合を回避する

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

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

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

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

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

  • 40-49は、サードパーティのパッケージ用に予約されています。

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

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

ヒント
ヒント

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

ヒント
ヒント

systemdコンポーネントの設定は、ファイルシステムのさまざまな場所に分散している可能性があるため、全体的な概要を把握するのが難しい場合があります。systemdコンポーネントの設定を調べるには、次のコマンドを使用します。

  • systemctl cat UNIT_PATTERNは、1つ以上のsystemdユニットに関連する設定ファイルを出力します。次に例を示します。

    > systemctl cat atd.service
  • systemd-analyze cat-config DAEMON_NAME_OR_PATHは、systemdデーモンの設定ファイルとドロップインのコンテンツをコピーします。次に例を示します。

    > systemd-analyze cat-config systemd/journald.conf

19.5.4 xinetdサービスをsystemdに変換する

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

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

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

# 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つの一致するファイルが必要です。

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

[Install]
WantedBy=sockets.target
# 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 socketserviceファイルオプションの完全なリストについては、systemd.socketおよびsystemd.serviceのマニュアルページ(man 5 systemd.socketman 5 systemd.service)を参照してください。

19.5.5 カスタムターゲットの作成

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

  1. 設定ファイル/usr/lib/systemd/system/graphical.target/etc/systemd/system/MY_TARGET.targetにコピーし、必要に応じて調整します。

  2. 前のステップでコピーした設定ファイルは、すでにターゲットの必須な(ハード)依存関係を構築した状態になっています。希望する(ソフト)依存関係も構築するには、/etc/systemd/system/MY_TARGET.target.wantsディレクトリを作成します。

  3. 希望するサービスごとに、/usr/lib/systemd/systemから/etc/systemd/system/MY_TARGET.target.wantsへのシンボリックリンクを作成します。

  4. ターゲットの設定が完了したら、新しいターゲットを利用できるようにするために、systemdの設定を再ロードします。

    > sudo systemctl daemon-reload

19.6 高度な使用方法

次のセクションでは、システム管理者向けの高度なトピックについて説明します。さらに高度なsystemdのドキュメントについては、Lennart Pöttering氏によるsystemdの資料(https://0pointer.de/blog/projects/)を参照してください。

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

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

19.6.2 システムログ

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

19.6.3 スナップショット

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

スナップショットの作成
> sudo systemctl snapshot MY_SNAPSHOT.snapshot
スナップショットの削除
> sudo systemctl delete MY_SNAPSHOT.snapshot
スナップショットの表示
> sudo systemctl show MY_SNAPSHOT.snapshot
スナップショットの有効化
> sudo systemctl isolate MY_SNAPSHOT.snapshot

19.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)のマニュアルページを参照してください。

19.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ユーザとして実行)。

> sudo systemctl daemon-reload
> sudo systemctl enable before

サービスファイルを変更するたびに、以下を実行する必要があります。

> sudo systemctl daemon-reload

19.6.6 カーネルのコントロールグループ(cgroup)

従来のSystem V initシステムでは、特定のプロセスを、その生成元のサービスと一致させることができないことがありました。Apacheなどの特定のサービスは、サードパーティのプロセス(CGIやJavaのプロセスなど)を多数生成し、サードパーティのプロセス自体もさらにプロセスを生成します。サービスに対する明確な割り当ては難しいことがあるだけでなく、場合によっては不可能であることもあります。特定の子プロセスを残して、サービスが正しく終了しないことも考えられます。

systemdでは、各プロセスを独自のcgroupに配置することでこの問題を解決しています。cgroupはプロセスをまとめるためのカーネルの機能で、すべての子プロセスを階層構造のグループとして管理します。systemdでは、各cgroupにそのサービスの名前が付けられています。非特権プロセスではcgroupから離脱できないため、サービスから生成したプロセスがどれなのかをサービス名によって判別できる効果的な仕組みです。

サービスに属するすべてのプロセスを表示するには、systemd-cglsコマンドを使用します。次に例を示します。

例 19.3: サービスに属するすべてのプロセスの表示
# 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を参照してください。

19.6.7 サービスの終了(シグナルの送信)

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

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

サービスに対するSIGTERMの送信

SIGTERMは、送信されるデフォルトのシグナルです。

> sudo systemctl kill MY_SERVICE
サービスに対するSIGNALの送信

-sオプションを使用することで、送信するシグナルを指定できます。

> sudo systemctl kill -s SIGNAL MY_SERVICE
プロセスの選択

デフォルトでは、killコマンドは、指定したcgroup内のall (すべての)プロセスに対してシグナルを送信します。control (制御)またはmain (メイン)のプロセスに対してだけ送信することもできます。限定されたプロセスに対する送信は、SIGHUPを送信して設定を再ロードさせるような場合に有効です。

> sudo systemctl kill -s SIGHUP --kill-who=main MY_SERVICE

19.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は更新されることに留意してください。

19.6.9 サービスのデバッグ

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

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

サービスの起動失敗の表示

サービスの起動に失敗した場合は、systemctl status MY_SERVICEを実行することで、詳細なエラーメッセージを表示することができます。

# systemctl start apache2
Job failed. See system journal and 'systemctl status' for details.
# systemctl status apache2
   Loaded: loaded (/usr/lib/systemd/system/apache2.service; disabled)
   Active: failed (Result: exit-code) since Mon, 04 Apr 2018 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

Apr 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パラメータを使用して実行してください。

> sudo systemctl status chronyd
> sudo systemctl --lines=20 status chronyd
追記モードによるサービスメッセージの表示

サービスメッセージをリアルタイムにを表示するには、--followオプションを使用します。このオプションは、tail -fに似た動作をします。

> sudo systemctl --follow status chronyd
メッセージの出力形式

--output=MODEパラメータを指定すると、サービスメッセージの出力形式を変更できます。最も重要なモードには次のものがあります。

short

デフォルトの形式。ログメッセージを、人間が読みやすいタイムスタンプと併記して表示します。

verbose

すべての項目を表示する完全な出力。

cat

タイムスタンプを併記しない、簡潔な出力。

19.7 systemdタイマユニット

cronと同様、systemdタイマユニットは、Linuxでジョブをスケジュールするためのメカニズムを提供します。systemdタイマユニットは、cronと同じ目的を果たしますが、いくつかの利点をがあります。

  • タイマユニットを使用してスケジュールされたジョブは、他のsystemdサービスに依存する可能性があります。

  • タイマユニットは通常のsystemdサービスとして扱われるため、systemctlで管理することができます。

  • タイマにはリアルタイムと単調があります。

  • タイマユニットはsystemdジャーナルに記録されるため、監視とトラブルシューティングが容易になります。

systemdタイマユニットは、.timerファイル名拡張子で識別されます。

19.7.1 systemdタイマタイプ

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

  • cronjobsと同様に、リアルタイムタイマはカレンダのイベントにトリガされます。リアルタイムタイマはオプションOnCalendarを使用して定義されます。

  • 単調タイマは特定の開始時点から指定の時間が経過するとトリガされます。後者はシステム起動イベントまたはまたはシステムユニットアクティベーションイベントのいずれかです。単調タイマを定義するオプションには、OnBootSecOnUnitActiveSecOnTypeSecなどがあります。単調タイマは、永続的ではなく、再起動するたびにリセットされます。

19.7.2 systemdタイマとサービスユニット

すべてのタイマユニットには、それが制御する対応するsystemdユニットファイルが必要です。つまり、.timerファイルは、対応する.serviceファイルを有効にし、管理します。タイマとともに使用する場合、.serviceファイルには[Install]セクションは必要ありません。サービスがタイマによって管理されるためです。

19.7.3 実例

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

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

> sudo  systemd-analyze verify /etc/systemd/system/foo.*

コマンドが出力を返さない場合、ファイルは検証に成功しています。

タイマを開始するには、コマンドsudo systemctl start foo.timerを使用します。起動時にタイマを有効にするには、コマンドsudo systemctl enable foo.timerを使用します。

19.7.4 systemdタイマの管理

タイマは通常のsystemdユニットとして扱われるため、systemctlを使用して管理できます。たとえば、systemctl startでタイマを起動し、systemctl enableでタイマを有効にできます。また、コマンドsystemctl list-timersを使用して、すべてのアクティブタイマを一覧表示できます。非アクティブなタイマを含むすべてのタイマを一覧表示するには、コマンドsystemctl list-timers --allを実行します。

19.8 詳細情報

systemdの詳細については、次のオンラインリソースを参照してください。

ホームページ

https://systemd.io/

管理者向けsystemd

systemdの著者のうちの1人、Lennart Pöttering氏によるブログに、systemdに関する複数の投稿があります(本章記述時点では13個の投稿)。それらは、次のサイトに記載されています。https://0pointer.de/blog/projects/