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

15 systemdデーモン

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

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

15.1 systemdの概念

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

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

  • 並列化機能

  • ソケットやD-Busアクティベーションを使用したサービスの起動

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

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

  • システム状態のスナップショットの作成と復元

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

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

15.1.1 ユニットファイル

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

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

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

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

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

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

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

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

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

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

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

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

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

15.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パッケージをインストールしておく必要があります。

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

tux > sudo systemctl start MY_1ST_SERVICE MY_2ND_SERVICE

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

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

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

表 15.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のほか、直近でサービスが出力したメッセージ(15.6.9項 「サービスのデバッグ」を参照)が表示されます。System V initで表示される詳細のレベルは、サービスごとに異なります。

status
status

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

is-active
status

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

上述のサービス管理コマンドでは、現在のセッションに対するサービスを操作できます。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

該当なし

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

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

15.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を介して恒久的に変更できます(15.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コマンドを使用します。

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

System Vランレベル

systemdターゲット

用途

0

runlevel0.targethalt.targetpoweroff.target

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

1、S

runlevel1.targetrescue.target

シングルユーザモード

2

runlevel2.targetmulti-user.target

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

3

runlevel3.targetmulti-user.target

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

4

runlevel4.target

未使用/ユーザ定義

5

runlevel5.targetgraphical.target

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

6

runlevel6.targetreboot.target

システムの再起動

重要
重要: systemd/etc/inittabが無視されることについて

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

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

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

タスク

systemdコマンド

System V initコマンド

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

systemctl isolate MY_TARGET.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.target

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

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

systemctl show -p "Requires" MY_TARGET.target

systemctl show -p "Wants" MY_TARGET.target

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

該当なし

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

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

15.3.2.1 サービスの起動の確認

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

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

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

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

[...]

15.3.2.2 起動時間のデバッグ

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

システムの起動時間の一覧表示
root # systemd-analyze
Startup finished in 2666ms (kernel) + 21961ms (userspace) = 24628ms
サービスの起動時間の一覧表示
root # 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
    [...]
サービスの起動時間を表す画像
root # systemd-analyze plot > jupiter.example.com-startup.svg
Image

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

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

systemd.log_level=debug systemd.log_target=kmsg

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

tux > dmesg -T | less

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

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

    1

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

    2

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

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

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

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

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

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

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

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

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

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

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

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

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

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

15.5 systemdのカスタマイズ

以降の各項には、systemdのカスタマイズ例が示されています。

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

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

15.5.1 ユニットファイルのカスタマイズ

ユニットファイルをカスタマイズするための推奨される方法は、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コマンドで呼び出すことが可能なマニュアルページを参照してください。

15.5.2 ドロップインファイルの作成

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

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

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

    .dサフィックスが付いていることに注意してください。それ以外の点では、このディレクトリは、ドロップインファイルでパッチ適用するサービスと同じ名前になります。

  2. ディレクトリ内に、your_modification.confファイルを作成します。

    このファイルには、変更する値が設定されている行のみを含めます。

  3. ファイルに変更内容を保存します。

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

ドロップインファイルと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を使用して、ユニット設定で考慮されるファイルを一覧表示し、確認することができます。

15.5.3 xinetdサービスのsystemdへの変換

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.socketman 5 systemd.service)を参照してください。

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

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の設定を再ロードします。

    tux > sudo systemctl daemon-reload

15.6 高度な使用方法

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

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

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.2 システムログ

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

15.6.3 スナップショット

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

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

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

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

tux > sudo systemctl daemon-reload
tux > sudo systemctl enable before

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

tux > sudo systemctl daemon-reload

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

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

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

サービスに属するすべてのプロセスを表示するには、systemd-cglsコマンドを使用します。次の例のような結果になります(一部省略しています)。

例 15.3: サービスに属するすべてのプロセスの表示
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.7 サービスの終了(シグナルの送信)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

short

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

verbose

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

cat

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

15.7 systemdタイマユニット

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

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

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

  • タイマはリアルタイムおよび単調にすることができます。

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

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

15.7.1 systemdタイマタイプ

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

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

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

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

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

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

オプション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を使用します。

15.7.4 systemdタイマの管理

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

15.8 詳細情報

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

ホームページ

http://www.freedesktop.org/wiki/Software/systemd

systemd (管理者向け)

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