第3章 systemd によるサービス管理

3.1. systemd の概要

Systemd は、Linux オペレーティングシステム用のシステムおよびサービスのマネージャーです。SysV init スクリプトと後方互換するように設計されており、起動時のシステムサービスの並行スタートアップや、デーモンのオンデマンドのアクティベーション、依存ベースのサービス制御論理などの多くの機能を提供します。Red Hat Enterprise Linux 7 以降、systemd は、Upstart に代わるデフォルトの init システムです。

systemd は、systemd unit の概念を導入します。このユニットは、次の表に挙げられているディレクトリーのいずれかにあるユニット設定ファイルで示されます。

表3.1 systemd unit ファイルの場所

ディレクトリー説明

/usr/lib/systemd/system/

インストール済みの RPM パッケージで配布された systemd unit ファイル。

/run/systemd/system/

ランタイム時に作成された systemd unit ファイル。このディレクトリーは、インストール済みのサービス unit ファイルのディレクトリーよりも優先されます。

/etc/systemd/system/

systemctl enable で作成された systemd unit ファイル、およびサービス拡張向けに追加された unit ファイル。このディレクトリーは、runtime unit ファイルのディレクトリーよりも優先されます。

ユニットは、次の情報をカプセル化します。

  • システムサービス
  • ソケットのリッスン
  • init システムに関連する他のオブジェクト

利用可能な systemd の unit タイプの完全なリストは、次の表を参照してください。

表3.2 利用可能な systemd unit タイプ

Unit タイプファイル拡張子説明

Service unit

.service

システムサービス

Target unit

.target

systemd unit のグループ

Automount unit

.automount

ファイルシステムの自動マウントポイント

Device unit

.device

カーネルが認識するデバイスファイル

Mount unit

.mount

ファイルシステムのマウントポイント

Path unit

.path

ファイルシステム内のファイルまたはディレクトリー

Scope unit

.scope

外部作成のプロセス

Slice unit

.slice

システムプロセスを管理する、階層的に構成された unit グループ

Socket unit

.socket

プロセス間の通信ソケット

Swap unit

.swap

スワップデバイスまたはスワップファイル

Timer unit

.timer

systemd タイマー

system.conf で、デフォルトの systemd 設定の上書き

systemd のデフォルト設定はコンパイル中に定義され、/etc/systemd/system.conf にある systemd 設定ファイルで確認できます。ここに記載されるデフォルトではなく、systemd ユニットで選択したデフォルト値をグローバルに上書きする場合は、このファイルを使用します。

たとえば、タイムアウト制限のデフォルト値 (90 秒) を上書きする場合は、DefaultTimeoutStartSec パラメータを使用して、上書きする値を秒単位で入力します。

DefaultTimeoutStartSec=required value

詳細は 例3.20「タイムアウト制限の変更」 を参照してください。

3.1.1. 主な特長

systemd システムおよびサービスマネージャーの主な機能は、以下のようになります。

  • ソケットベースのアクティベーション - システムの起動時に、systemd は、このタイプのアクティベーションに対応するすべてのシステムサービスに対してリスニングソケットを作成し、サービスが開始するとすぐにこのソケットをサービスに渡します。これで systemd がサービスを同時に開始できるだけでなく、サービスが利用できない時に送信されたメッセージを失うことなくサービスの再起動が可能になります。これは、対応するソケットがアクセス可能なままで、すべてのメッセージがキューに登録されるためです。

    systemd は、ソケットベースの有効化に ソケットユニット を使用します。

  • バスベースのアクティベーション - プロセス間の通信に D-Bus を使用するシステムサービスは、クライアントアプリケーションがシステムサービスとの通信を初めて試みる時にオンデマンドで開始します。Systemd は、バスベースのアクティベーションに D-Bus サービスファイル を使用します。
  • デバイスベースのアクティベーション - デバイスベースのアクティベーションをサポートするシステムサービスは、特定のタイプのハードウェアがプラグインするか利用可能になると、オンデマンドで開始できます。Systemd は、デバイスユニット デバイスベースのアクティベーションを行います。
  • パスベースのアクティベーション - パスベースのアクティベーションをサポートするシステムサービスは、特定のファイルまたはディレクトリーの状態が変更になると、オンデマンドで開始できます。Systemd は、パスユニット を使用して、パスベースのアクティベーションを行います。
  • マウントおよび自動マウントポイント管理 - Systemd は、マウントポイントおよび自動マウントポイントを監視および管理します。Systemd は、マウントポイントに mount unit を使用し、自動マウントポイントに automount unit を使用します。
  • アグレッシブな並列化 - ソケットベースのアクティベーションを使用するため、systemd はすべてのリスニングソケットが配置されるとすぐに、システムサービスを同時に開始できます。並列アクティベーションは、オンデマンドのアクティベーションをサポートするシステムサービスと組み合わせることで、システム起動に必要な時間を大幅に短縮します。
  • トランザクション性のある unit のアクティベーション論理 - unit をアクティブまたは非アクティブにする前に、systemd はその依存関係を計算して、一時的なトランザクションを作成し、このトランザクションの一貫性を検証します。トランザクションに一貫性がない場合、systemd は自動的にこれを正そうとし、エラーをレポートする前に必須ではないジョブを削除しようと試みます。
  • SysV init との後方互換性 - Linux Standard Base Core Specification にあるように、Systemd は SysV init スクリプトに対応しています。これにより、systemd サービスの unit へのアップグレードが容易になります。

3.1.2. 互換性の変更点

systemd システムおよびサービスマネージャーは、SysV init および Upstart と大部分が互換するように設計されています。以下では、SysV init を使用していた Red Hat Enterprise Linux 6 システムと比較して、互換性について最も重要な変更点を挙げています。

  • Systemd のランレベルのサポートは限定的なものです。ランレベルに直接マッピング可能なターゲットユニットを数多く提供し、互換性のために以前の runlevel コマンドで配布されます。ただし、systemd ターゲットのすべてがランレベルに直接マッピング可能な訳ではないため、このコマンドが不明なランレベルを示す N を返す場合もあります。可能な場合は、runlevel コマンドの使用を避けることが推奨されます。
    systemd ターゲットの詳細と、ランレベルとの比較は 「systemd ターゲットでの作業」 を参照してください。
  • systemctl ユーティリティーは、カスタマイズされたコマンドをサポートしません。SysV init スクリプトでは、startstopstatus といった標準のコマンドのほかに、任意のコマンドを実装して多くの機能を提供できます。たとえば、iptables の init スクリプトは、panic コマンドで実行できます。これにより、パニックモードが即座に有効になり、システムを再設定して受信パケットおよび送信パケットをすべて切断します。これは systemd ではサポートされておらず、systemctl は文書化されたコマンドのみ受け付けます。

    systemctl ユーティリティー、および以前の service ユーティリティーとの比較は 表3.3「service ユーティリティーと systemctl の比較」 を参照してください。

  • systemctl ユーティリティーは、systemd が開始していないとサービスとは通信しません。systemd がシステムサービスを開始すると、メインプロセスの ID を保存して、メインプロセスを追跡します。すると、systemctl ユーティリティーはこの PID を使用してクエリーを行い、サービスを管理します。このため、ユーザーがコマンドラインで特定のデーモンを直接開始すると、systemctl が最新の状態を判断したり、これを停止したりできません。
  • Systemd が停止するのは、実行中のサービスのみです。Red Hat Enterprise Linux 6 以前のリリースでは、シャットダウンシーケンスが開始すると、/etc/rc0.d/ ディレクトリーにあるシンボリックリンクを使用して、利用可能なシステムサービスをそのステータスに関係なくすべて停止していました。systemd では、シャットダウン時に停止するのは、実行中のサービスのみになります。
  • システムサービスは、標準の入力ストリームからは読み取れません。systemd がサービスを開始すると、標準入力を /dev/null に接続し、ユーザーとのインタラクションを防ぎます。
  • システムサービスは、開始したユーザーやそのセッションから、(環境変数 HOMEPATH などの) コンテキストを継承しません。各サービスは、クリーンな実行コンテキストで実行します。
  • SysV init スクリプトを読み込む際に、systemd は Linux Standard Base (LSB) ヘッダーにエンコードされている依存関係情報を読み取り、ランタイム時に解釈します。
  • サービスユニット上のすべての操作は 5 分間でタイムアウトするようにデフォルト設定になっており、サービスの故障でシステムがフリーズすることを防ぎます。この値は initscript から生成されるサービス用にハードコーディングされ、変更することができません。ただし、個別の設定ファイルを使用してサービス別にタイムアウト値を長くできます。例3.20「タイムアウト制限の変更」 を参照してください。

systemd で導入された互換性の変更点に関する詳細なリストは、Red Hat Enterprise Linux 7 の『Migration Planning Guide』を参照してください。

3.2. システムサービスの管理

以前のバージョンの Red Hat Enterprise Linux は、SysV init または Upstart で配布されており、/etc/rc.d/init.d/ ディレクトリーにある init スクリプト を使用していました。この init スクリプトは通常の Bash で書かれており、システム管理者がシステムの状態とシステム内のデーモンを管理できるようになっていました。Red Hat Enterprise Linux 7 では、この init スクリプトは、サービスユニット に代わっています。

サービスユニットは、ファイル拡張子 .service で終わり、init スクリプトと同様の役割を担います。システムサービスの表示、開始、停止、再開、有効化、無効化には、「service ユーティリティーと systemctl の比較」「chkconfig ユーティリティーと systemctl の比較」、および本セクションで説明されているように、systemctl コマンドを使用します。service コマンドおよび chkconfig コマンドは、引き続きシステムで利用可能になっており、期待通りに機能しますが、これらは互換性のために含まれており、使用は推奨されていません。

表3.3 service ユーティリティーと systemctl の比較

servicesystemctl説明

service name start

systemctl start name.service

サービスを起動します。

service name stop

systemctl stop name.service

サービスを停止します。

service name restart

systemctl restart name.service

サービスを再起動します。

service name condrestart

systemctl try-restart name.service

サービスが実行中の場合のみ、再起動します。

service name reload

systemctl reload name.service

設定を再読み込みします。

service name status

systemctl status name.service

systemctl is-active name.service

サービスが実行中かどうかをチェックします。

service --status-all

systemctl list-units --type service --all

すべてのサービスのステータスを表示します。

表3.4 chkconfig ユーティリティーと systemctl の比較

chkconfigsystemctl説明

chkconfig name on

systemctl enable name.service

サービスを有効にします。

chkconfig name off

systemctl disable name.service

サービスを無効にします。

chkconfig --list name

systemctl status name.service

systemctl is-enabled name.service

サービスが有効かどうかを確認します。

chkconfig --list

systemctl list-unit-files --type service

サービスを一覧表示し、各サービスが有効かどうかを確認します。

chkconfig --list

systemctl list-dependencies --after

指定されたユニットの前に開始するよう命令されるサービスを一覧表示します。

chkconfig --list

systemctl list-dependencies --before

指定されたユニットの後に開始するように命令されるサービスを一覧表示します。

サービスユニットの指定

明確化を図るため、本セクションの残りの部分のコマンド例では、.service ファイル拡張子がついた完全なユニット名を使用します。例を示します。

~]# systemctl stop nfs-server.service

ただし、ファイル拡張子は省略することが可能で、その場合、systemctl は、引数がサービスユニットであることを想定します。以下のコマンドは、上記のコマンドと同等のものになります。

~]# systemctl stop nfs-server

また、ユニットによってはエイリアス名を持つものもあります。この名前はユニット名よりも短いことがあり、ユニット名の代わりとして使用できます。特定のユニットに使用可能なエイリアスを見つけるには、以下のコマンドを実行します。

~]# systemctl show nfs-server.service -p Names

chroot 環境における systemctl の挙動

chroot コマンドを使用して root ディレクトリーを変更すると、ほとんどの systemctl コマンドは、アクションの実行をすべて拒否します。なぜなら、systemd プロセスと、chroot コマンドを使用しているユーザーでは、ファイルシステムの見え方が異なるからです。このような状況は、systemctlキックスタート ファイルから呼び出されたときなどに発生します。

例外が、systemctl enablesystemctl disable などのユニットファイルコマンドです。このコマンドは、実行中のシステムを必要とせず実行中のプロセスに影響を与えませんが、ユニットファイルには影響を及ぼします。したがってこのようなコマンドは、chroot 環境であっても実行することが可能です。たとえば、/srv/website1/ ディレクトリー配下で、システムの httpd サービスを有効にするときは、以下のコマンドを使用します。

~]# chroot /srv/website1
~]# systemctl enable httpd.service
Created symlink /etc/systemd/system/multi-user.target.wants/httpd.service, pointing to /usr/lib/systemd/system/httpd.service.

3.2.1. サービスの一覧表示

読み込み済みの最新サービスユニットの一覧を表示するには、シェルプロンプトで以下を実行します。

systemctl list-units --type service

各サービスのユニットファイルに対して、このコマンドは正式名 (UNIT) の後に、そのユニットファイルがロードされているかどうか (LOAD)、そのユニットファイルアクティベーションの状態の概要 (ACTIVE) および詳細 (SUB) な状態、簡単な説明 (DESCRIPTION) と示します。

デフォルトでは、systemctl list-units コマンドは、アクティブなユニットのみを表示します。状態に関係なく読み込み済みユニットをすべて表示する場合は、--all または -a コマンドラインオプションで以下のコマンドを実行します。

systemctl list-units --type service --all

また、利用可能なサービスユニットを一覧表示して、各ユニットが有効かどうかを確認できます。これには、以下のコマンドを実行します。

systemctl list-unit-files --type service

このコマンドにより、各サービスユニットの完全な名前 (UNIT FILE) と、サービスユニットが有効かどうか (STATE) が表示されます。個別のサービスユニットの状態を判断する方法は 「Displaying service status」 を参照してください。

例3.1 サービスの一覧表示

現在読み込み済みのサービスユニットの一覧を表示するには、以下のコマンドを実行します。

~]$ systemctl list-units --type service
UNIT                           LOAD   ACTIVE SUB     DESCRIPTION
abrt-ccpp.service              loaded active exited  Install ABRT coredump hook
abrt-oops.service              loaded active running ABRT kernel log watcher
abrt-vmcore.service            loaded active exited  Harvest vmcores for ABRT
abrt-xorg.service              loaded active running ABRT Xorg log watcher
abrtd.service                  loaded active running ABRT Automated Bug Reporting Tool
…​
systemd-vconsole-setup.service loaded active exited  Setup Virtual Console
tog-pegasus.service            loaded active running OpenPegasus CIM Server

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.

46 loaded units listed. Pass --all to see loaded but inactive units, too.
To show all installed unit files use 'systemctl list-unit-files'

インストール済みのサービスユニットファイルを一覧表示して、そのユニットが有効かどうかを判断するには、以下コマンドを実行します。

~]$ systemctl list-unit-files --type service
UNIT FILE                                   STATE
abrt-ccpp.service                           enabled
abrt-oops.service                           enabled
abrt-vmcore.service                         enabled
abrt-xorg.service                           enabled
abrtd.service                               enabled
…​
wpa_supplicant.service                      disabled
ypbind.service                              disabled

208 unit files listed.

3.2.2. サービスステータスの表示

システムサービスに対応するサービスユニットに関する詳細情報を表示するには、シェルプロンプトで以下を実行します。

systemctl status name.service

name を、確認するサービスユニット名 (gdm など) に置き換えます。このコマンドでは、選択したサービスユニット名の後に、その説明と、表3.5「利用可能なサービスユニットの情報」 にある 1 つ以上のフィールド、さらに root ユーザーが実行している場合は最新のログエントリーが表示されます。

表3.5 利用可能なサービスユニットの情報

フィールド説明

Loaded

サービスユニットが読み込まれているかどうか、ユニットファイルへの絶対パス、ユニットが有効かどうかについての説明

Active

サービスユニットが実行中かどうかの情報と、タイムスタンプ

Main PID

対応するシステムサービスの PID と、その名前

Status

対応するシステムサービスに関する追加情報

Process

関連プロセスに関する追加情報

CGroup

関連するコントロールグループ (cgroup) に関する追加情報

特定のサービスユニットが実行中かどうかだけを確認する場合は、以下のコマンドを実行します。

systemctl is-active name.service

同様に、特定のサービスユニットが有効かどうかを確認するには、以下のコマンドを実行します。

systemctl is-enabled name.service

systemctl is-active および systemctl is-enabled は両方とも、指定したサービスユニットが実行中または有効な場合に、0 の終了ステータスを返すことに注意してください。現在読み込み済みのサービスユニットの一覧を表示する方法は Listing services を参照してください。

例3.2 サービスステータスの表示

GNOME Display Manager のサービスユニット名は gdm.service になります。このサービスユニットの現在のステータスを確認するには、シェルプロンプトで次のコマンドを実行します。

~]# systemctl status gdm.service
gdm.service - GNOME Display Manager
   Loaded: loaded (/usr/lib/systemd/system/gdm.service; enabled)
   Active: active (running) since Thu 2013-10-17 17:31:23 CEST; 5min ago
 Main PID: 1029 (gdm)
   CGroup: /system.slice/gdm.service
           ├─1029 /usr/sbin/gdm
           ├─1037 /usr/libexec/gdm-simple-slave --display-id /org/gno…​
           └─1047 /usr/bin/Xorg :0 -background none -verbose -auth /r…​

Oct 17 17:31:23 localhost systemd[1]: Started GNOME Display Manager.

例3.3 サービスの前に開始するサービスの表示

特定のサービスの前に開始するサービスを確認するには、シェルプロンプトで次のコマンドを実行します。

~]# systemctl list-dependencies --after gdm.service
gdm.service
├─dbus.socket
├─getty@tty1.service
├─livesys.service
├─plymouth-quit.service
├─system.slice
├─systemd-journald.socket
├─systemd-user-sessions.service
└─basic.target
[output truncated]

例3.4 サービスの後に開始するサービスの表示

特定のサービスの後に開始するサービスを確認するには、シェルプロンプトで次のコマンドを実行します。

~]# systemctl list-dependencies --before gdm.service
gdm.service
├─dracut-shutdown.service
├─graphical.target
│ ├─systemd-readahead-done.service
│ ├─systemd-readahead-done.timer
│ └─systemd-update-utmp-runlevel.service
└─shutdown.target
  ├─systemd-reboot.service
  └─final.target
    └─systemd-reboot.service

3.2.3. サービスの起動

システムサービスに対応するサービスユニットを開始するには、シェルプロンプトで、 root で次のコマンドを実行します。

systemctl start name.service

name を、開始するサービスユニット名 (たとえば、gdm) に置き換えます。このコマンドは、選択したサービスを現行セッションで開始します。システムの起動時にサービスユニットを開始するように設定する方法は 「Enabling a service」 を参照してください。特定のサービスユニットのステータスを判断する方法は 「Displaying service status」 を参照してください。

例3.5 サービスの起動

Apache HTTP サーバー用のサービスユニットは httpd.service です。サービスユニットをアクティブにし、現行セッションで httpd デーモンを起動するには、root で以下のコマンドを実行します。

~]# systemctl start httpd.service

3.2.4. サービスの停止

システムサービスに対応するサービスユニットを停止するには、root で次のコマンドを実行します。

systemctl stop name.service

name を、停止するサービスユニット名 (たとえば bluetooth) に置き換えます。このコマンドは、選択したサービスユニットを現行セッションで停止します。システムの起動時にサービスユニットを無効にし、開始しないようにする方法は「Disabling a service」を参照してください。特定のサービスユニットの状態を確認する方法は「Displaying service status」を参照してください。

例3.6 サービスの停止

bluetoothd デーモンのサービスユニットは bluetooth.service です。サービスユニットを無効にし、現行セッションで bluetoothd デーモンを停止するには、root で以下のコマンドを実行します。

~]# systemctl stop bluetooth.service

3.2.5. サービスの再開

システムサービスに対応するサービスユニットを再開するには、root で次のコマンドを実行します。

systemctl restart name.service

name を、再開するサービスユニット名 (たとえば、httpd) に置き換えます。このコマンドは、選択したサービスユニットを現行セッションで停止し、即座に再起動します。重要なのは、選択したサービスユニットが実行中でないと、このコマンドがそのサービスユニットを起動するということです。対応するサービスがすでに実行中の場合にのみ、サービスユニットを再起動するように systemd に設定するには、root で以下のコマンドを実行します。

systemctl try-restart name.service

システムサービスによっては、サービスの実行を中断することなく設定の再読み込みが可能です。これを実行するには、root で次のコマンドを実行します。

systemctl reload name.service

システムサービスがこの機能をサポートしない場合は、このコマンドが無視されることに注意してください。代わりに、systemctl コマンドでは、この機能をサポートしないサービスを再起動する reload-or-restart コマンドおよび reload-or-try-restart コマンドもサポートします。サービスユニットのステータスを確認する方法は 「サービスステータスの表示」を参照してください。

例3.7 サービスの再開

ユーザーが不要なエラーメッセージや部分的に表示される Web ページに遭遇しないようにするため、Apache HTTP Server では設定を再起動したり、処理されたリクエストをアクティブに妨害したりせずに、設定を編集したり再読み込みしたりできます。これを行うには、root で次のコマンドを実行します。

~]# systemctl reload httpd.service

3.2.6. サービスの有効化

システムの起動時にシステムサービスに対応するサービスユニットを自動的に起動するように設定するには、root で次のコマンドを実行します。

systemctl enable name.service

name を、有効にするサービスユニット名 (httpd など) に置き換えます。このコマンドは、選択したサービスユニットの[Install] セクションを読み取り、/etc/systemd/system/ ディレクトリーおよびそのサブディレクトリーにある /usr/lib/systemd/system/name.service ファイルへの適切なシンボリックリンクを作成します。ただし、このコマンドは既存のリンクを上書きしません。シンボリックリンクが確実に再度作成されるようにするには、root で以下のコマンドを実行します。

systemctl reenable name.service

このコマンドは、選択したサービスユニットを無効にし、即座に再度有効にします。システムの起動時に特定のサービスユニットが有効になるかどうかを確認する方法は 「Displaying service status」 を参照してください。現行セッションでサービスを開始する方法は 「Starting a service」 を参照してください。

例3.8 サービスの有効化

システムの起動時に Apache HTTP Server が自動的に開始するように設定するには、root で以下のコマンドを実行します。

~]# systemctl enable httpd.service
Created symlink from /etc/systemd/system/multi-user.target.wants/httpd.service to /usr/lib/systemd/system/httpd.service.

3.2.7. サービスの無効化

システムの起動時に、システムサービスに対応するサービスユニットを自動的に起動しないように設定するには、root で次のコマンドを実行します。

systemctl disable name.service

name を、無効にするサービスユニット名 (bluetooth など) に置き換えます。このコマンドは、選択したサービスユニットの [Install] セクションを読み取り、/etc/systemd/system/ ディレクトリーおよびそのサブディレクトリーから、/usr/lib/systemd/system/name.service ファイルへの適切なシンボリックリンクを削除します。さらに、サービスユニットにマスクをして、手動で開始したり、別のサービスがこれを開始することを防いだりできます。これを実行するには、root で以下のコマンドを実行します。

systemctl mask name.service

このコマンドにより、/etc/systemd/system/name.service ファイルを、/dev/null へのシンボリックリンクに置き換え、実際のユニットファイルが systemd ファイルにアクセスできないようにします。この動作を元に戻してサービスユニットのマスクを解除するには、root で以下のコマンドを実行します。

systemctl unmask name.service

特定のサービスユニットがシステムの起動時に有効になるかどうかを確認する方法は「Displaying service status」を参照してください。現行セッションでサービスを停止する方法は「Stopping a service」を参照してください。

例3.9 サービスの無効化

例3.6「サービスの停止」 では、現行セッションで bluetooth.service ユニットを停止する方法を説明しました。このサービスユニットが起動時に開始しないようにするには、root で次のコマンドを実行します。

~]# systemctl disable bluetooth.service
Removed symlink /etc/systemd/system/bluetooth.target.wants/bluetooth.service.
Removed symlink /etc/systemd/system/dbus-org.bluez.service.

3.2.8. 競合するサービスの起動

systemd では、サービス間に正と負の依存関係が存在します。特定のサービスを起動するとき、別のサービスを 1 つまたは複数起動 (正の依存関係)、あるいはサービスを 1 つまたは複数停止 (負の依存関係) することが必要となる場合があります。

ユーザーが新しいサービスを起動しようとすると、systemd がすべての依存関係を自動的に解決します。これは、ユーザーに明示的に通知されることなく実行されるため注意が必要です。サービスが実行されているときに、負の依存関係を持つ別のサービスを起動しようとすると、実行しているサービスが自動的に停止します。

たとえば、postfix サービスを実行している時に sendmail サービスを起動すると、systemd は、自動的に postfix を停止します。この 2 つのサービスは競合するため、同じポートでは実行できません。

3.3. systemd ターゲットでの作業

以前のバージョンの Red Hat Enterprise Linux は、SysV init または Upstart で配布されており、特定モードのオペレーションを表す事前定義の ランレベル を実装していました。このランレベルは 0 から 6 までの数字で表され、システム管理者が各ランレベルを有効にしたときに実行されるシステムサービスが定義されていました。Red Hat Enterprise Linux 7 では、ランレベルの概念が systemd ターゲット に代わっています。

Systemd ターゲットは ターゲットユニット で表されます。ターゲットユニットは .target ファイル拡張子で終わり、その唯一の目的は依存関係の連鎖で他の systemd ユニットをグループ化することです。たとえば、グラフィカルセッションの開始に使用する graphical.target ユニットは、GNOME Display Manager (gdm.service) または Accounts Service (accounts-daemon.service) といったシステムサービスを開始するとともに、multi-user.target ユニットもアクティブにします。同様に、multi-user.target ユニットは、NetworkManager (NetworkManager.service)、D-Bus (dbus.service) といった、その他の必須システムサービスを開始し、basic.target という別のターゲットユニットをアクティブにします。

Red Hat Enterprise Linux 7 では、以前のシステムリリースの標準ランレベルと類似する定義済みターゲットが多数同梱されています。互換性目的で、このターゲットを SysV ランレベルに直接マッピングするエイリアスも提供されています。表3.6「SysV ランレベルと systemd ターゲットの比較」では、SysV ランレベルの完全なリストと、対応する systemd ターゲットが表示されています。

表3.6 SysV ランレベルと systemd ターゲットの比較

ランレベルターゲットユニット説明

0

runlevel0.target, poweroff.target

システムをシャットダウンし、電源を切ります。

1

runlevel1.target, rescue.target

レスキューシェルを設定します。

2

runlevel2.target, multi-user.target

非グラフィカルなマルチユーザーシステムを設定します。

3

runlevel3.target, multi-user.target

非グラフィカルなマルチユーザーシステムを設定します。

4

runlevel4.target, multi-user.target

非グラフィカルなマルチユーザーシステムを設定します。

5

runlevel5.target, graphical.target

グラフィカルな複数ユーザーシステムを設定します。

6

runlevel6.target, reboot.target

システムをシャットダウンして再起動します。

systemd ターゲットを表示、変更、または設定するには、 表3.7「SysV init コマンドと systemctl の比較」 および以下のセクションの説明に従って systemctl ユーティリティーを使用します。runlevel および telinit の各コマンドは今も利用でき、期待どおりに機能しますが、このコマンドは互換性のために同梱されているため、なるべく使用しないでください。

表3.7 SysV init コマンドと systemctl の比較

古いコマンド新しいコマンド説明

runlevel

systemctl list-units --type target

現在読み込まれているターゲットユニットを表示します。

telinit runlevel

systemctl isolate name.target

現在のターゲットを変更します。

3.3.1. デフォルトターゲットの表示

デフォルトでどのターゲットユニットが使用されるかを決定するには、以下のコマンドを実行します。

systemctl get-default

このコマンドは、/etc/systemd/system/default.target にあるシンボリックリンクを解決して、結果を表示します。

例3.10 デフォルトターゲットの表示

デフォルトのターゲットユニットを表示するには、以下のコマンドを実行します。

~]$ systemctl get-default
graphical.target

3.3.2. 現在のターゲットの表示

読み込み済みの現在のターゲットユニットの一覧を表示するには、シェルプロンプトで以下のコマンドを実行します。

systemctl list-units --type target

このコマンドを実行すると、各ターゲットユニットの正式名 (UNIT) の後に、そのユニットが読み込まれているかどうか (LOAD)、そのユニットファイルアクティベーションの状態の概要 (ACTIVE) および詳細 (SUB) な状態、簡単な説明 (DESCRIPTION) が表示されます。

デフォルトでは、systemctl list-units コマンドは、アクティブなユニットのみを表示します。状態に関係なく読み込み済みユニットをすべて表示する場合は、--all または -a コマンドラインオプションで以下のコマンドを実行します。

systemctl list-units --type target --all

例3.11 現在のターゲットの表示

現在読み込み済みのターゲットユニットの一覧を表示するには、以下のコマンドを実行します。

~]$ systemctl list-units --type target
UNIT                  LOAD   ACTIVE SUB    DESCRIPTION
basic.target          loaded active active Basic System
cryptsetup.target     loaded active active Encrypted Volumes
getty.target          loaded active active Login Prompts
graphical.target      loaded active active Graphical Interface
local-fs-pre.target   loaded active active Local File Systems (Pre)
local-fs.target       loaded active active Local File Systems
multi-user.target     loaded active active Multi-User System
network.target        loaded active active Network
paths.target          loaded active active Paths
remote-fs.target      loaded active active Remote File Systems
sockets.target        loaded active active Sockets
sound.target          loaded active active Sound Card
spice-vdagentd.target loaded active active Agent daemon for Spice guests
swap.target           loaded active active Swap
sysinit.target        loaded active active System Initialization
time-sync.target      loaded active active System Time Synchronized
timers.target         loaded active active Timers

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.

17 loaded units listed. Pass --all to see loaded but inactive units, too.
To show all installed unit files use 'systemctl list-unit-files'.

3.3.3. デフォルトターゲットの変更

システムがデフォルトで異なるターゲットユニットを使用するように設定するには、root で次のコマンドを実行します。

systemctl set-default name.target

name を、デフォルトで使用するターゲットユニットの名前 (multi-user など) を置き換えます。このコマンドにより、/etc/systemd/system/default.target ファイルが、/usr/lib/systemd/system/name.target へのシンボリックリンクに置き換わります。name は、使用するターゲットユニットの名前になります。

例3.12 デフォルトターゲットの変更

デフォルトで multi-user.target ユニットを使用するようにシステムを設定するには、root で以下のコマンドを実行します。

~]# systemctl set-default multi-user.target
rm '/etc/systemd/system/default.target'
ln -s '/usr/lib/systemd/system/multi-user.target' '/etc/systemd/system/default.target'

3.3.4. 現在のターゲットの変更

現行のセッションで異なるターゲットユニットに変更するには、root で次のコマンドを実行します。

systemctl isolate name.target

name を、使用するターゲットユニットの名前 (multi-user など) に置き換えます。このコマンドは、name という名前のターゲットユニットと、その従属ユニットをすべて起動し、その他のユニットを直ちに停止します。

例3.13 現在のターゲットの変更

グラフィカルユーザーインターフェイスを無効にし、現行セッションで multi-user.target ユニットに変更するには、root で以下のコマンドを実行します。

~]# systemctl isolate multi-user.target

3.3.5. レスキューモードへの変更

レスキューモード は、便利なシングルユーザー環境を提供し、通常の起動プロセスを完了できない状況でのシステムの修復を可能にします。レスキューモードでは、システムはすべてのローカルファイルシステムのマウントと、いくつかの重要なシステムサービスの開始を試みますが、ネットワークインターフェースをアクティブにしたり、他のユーザーによるシステムへの同時ログインを許可したりすることはしません。レスキューモードでは、root パスワードが要求されます。

現在のターゲットを変更し、現行セッションでレスキューモードに入るには、root で次のコマンドを実行します。

systemctl rescue

このコマンドは systemctl isolate rescue.target と似ていますが、システムに現在ログインしているすべてのユーザーに情報メッセージを送信します。systemd がこのメッセージを送信しないようにするには、コマンドラインオプション --no-wall を付けてこのコマンドを実行します。

systemctl --no-wall rescue

緊急モードに入る方法は 「緊急モードへの変更」 を参照してください。

例3.14 レスキューモードへの変更

現行セッションでレスキューモードに入るには、root で以下のコマンドを実行します。

~]# systemctl rescue

Broadcast message from root@localhost on pts/0 (Fri 2013-10-25 18:23:15 CEST):

The system is going down to rescue mode NOW!

3.3.6. 緊急モードへの変更

緊急モード は、可能な限り最小限の環境を提供し、レスキューモードに入れないシステム状態でのシステムの修復を可能にします。緊急モードでは、システムは root ファイルシステムを読み込み専用でマウントし、他のローカルファイルシステムのマウントは試みません。また、ネットワークインターフェースのアクティブ化も行わず、限定的な必須サービスのみを起動します。緊急モードでは root パスワードが必要です。

現在のターゲットを変更し、緊急モードに入るには、root で次のコマンドを実行します。

systemctl emergency

このコマンドは systemctl isolate emergency.target と似ていますが、システムに現在ログインしているすべてのユーザーに情報メッセージを送信します。systemd がこのメッセージを送信しないようにするには、コマンドラインオプション --no-wall を付けてこのコマンドを実行します。

systemctl --no-wall emergency

レスキューモードに入る方法は 「レスキューモードへの変更」 を参照してください。

例3.15 緊急モードへの変更

現在システムにログインしている全ユーザーにメッセージを送信せずに緊急モードに入るには、root で以下のコマンドを実行します。

~]# systemctl --no-wall emergency

3.4. システムのシャットダウン、サスペンド、および休止状態

Red Hat Enterprise Linux 7 では、systemctl ユーティリティーが、これまでのバージョンの Red Hat Enterprise Linux システムで使用されていた多くの電源管理コマンドに置き換わっています。表3.8「電源管理コマンドと systemctl の比較」 に表示されているコマンドは、互換性の理由から現在も利用することはできますが、可能な場合は systemctl の使用が推奨されます。

表3.8 電源管理コマンドと systemctl の比較

古いコマンド新しいコマンド説明

halt

systemctl halt

システムを停止します。

poweroff

systemctl poweroff

システムの電源を切ります。

reboot

systemctl reboot

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

pm-suspend

systemctl suspend

システムをサスペンドします。

pm-hibernate

systemctl hibernate

システムを休止状態にします。

pm-suspend-hybrid

systemctl hybrid-sleep

システムを休止状態にしてサスペンドします。

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

systemctl ユーティリティーは、システムをシャットダウンするコマンドを提供します。ただし、従来の shutdown コマンドもサポートされます。shutdown コマンドは、systemctl ユーティリティーを呼び出してシャットダウンを実行しますが、time 引数もサポートするという利点があります。これは、計画メンテナンスにとりわけ役立ち、システムシャットダウンの予定に関する警告にユーザーが対応する時間をより長く確保できます。シャットダウンをキャンセルするオプションがあることも利点です。

systemctl コマンドの使用

システムをシャットダウンし、マシンの電源を切るには、root で次のコマンドを実行します。

systemctl poweroff

マシンの電源を切らずにシステムをシャットダウンして停止するには、root で以下のコマンドを実行します。

systemctl halt

デフォルトでは、このコマンドのいずれかを実行すると、systemd が、システムに現在ログインしたすべてのユーザーに情報メッセージを送信します。systemd がメッセージを送信しないようにするには、たとえば、コマンドラインで --no-wall オプションを付けてコマンドを実行します。

systemctl --no-wall poweroff

shutdown コマンドの使用

指定した時間にシステムをシャットダウンしてマシンの電源を切るには、root で、以下の形式でコマンドを実行します。

shutdown --poweroff hh:mm

hh:mm は 24 時間形式の時刻となります。新たなログインを防ぐために、システムをシャットダウンする 5 分前に /run/nologin ファイルが作成されます。時間引数を使用する場合は、コマンドに任意のメッセージ wall message を付けることができます。

マシンの電源を切らずに、少し待ってシステムをシャットダウンして停止するには、root で以下の形式のコマンドを実行します。

shutdown --halt +m

ここで、+m は遅らせる時間 (分) です。now キーワードは +0 のエイリアスとなります。

保留中のシャットダウンは、root で以下のコマンドを実行するとキャンセルできます。

shutdown -c

詳細なコマンドオプションは、man ページの shutdown(8) を参照してください。

3.4.2. システムの再起動

システムを再起動するには、root で以下のコマンドを実行します。

systemctl reboot

デフォルトでは、このコマンドにより、systemd が、システムに現在ログインしたすべてのユーザーに情報メッセージを送信します。systemd がメッセージを送信しないようにするには、--no-wall コマンドラインオプションを付けてこのコマンドを実行します。

systemctl --no-wall reboot

3.4.3. システムのサスペンド

システムをサスペンドするには、root で次のコマンドを実行します。

systemctl suspend

このコマンドは、システムの状態を RAM に保存し、RAM モジュール以外のほとんどのデバイスの電源を切ります。マシンの電源を戻すと、システムは再起動せずに RAM からその状態を復元します。システムの状態がハードディスクではなく RAM に保存されるので、システムのサスペンドモードから復元する場合は、休止状態からの復元と比べて大幅に速くなります。ただし、システムをサスペンドした状態は、停電に対して脆弱となります。

システムを休止状態にする方法は 「システムの休止状態」 を参照してください。

3.4.4. システムの休止状態

システムをハイバーネートにするには、root で次のコマンドを実行します。

systemctl hibernate

このコマンドは、システムの状態をハードディスクドライブに保存し、マシンの電源を切ります。マシンの電源を戻すと、システムは再起動せずに保存されたデータからその状態を復元します。システムの状態が RAM ではなくハードディスクに保存されるので、マシンが RAM モジュールに電力を維持する必要がありません。ただし、システムの休止状態から復元する場合は、サスペンドモードからの復元と比べて大幅に遅くなります。

システムを休止状態にしてサスペンドするには、root で次のコマンドを実行します。

systemctl hybrid-sleep

システムをサスペンドする方法は 「システムのサスペンド」 を参照してください。

3.5. systemd ユニットファイルでの作業

ユニットファイルには、ユニットを説明し、その動作を定義する設定ディレクティブが含まれます。複数の systemctl コマンドがバックグラウンドでユニットファイルと連携します。細かい調整を行うには、システム管理者は手動でユニットファイルを編集するか、または作成する必要があります。表3.1「systemd unit ファイルの場所」 には、システム上のユニットファイルが保存される 3 つのメインディレクトリーが挙げられていますが、/etc/systemd/system/ ディレクトリーは、システム管理者が作成するか、またはカスタマイズするユニットファイル用に予約されます。

ユニットファイル名は、以下のフォーマットを使用します。

unit_name.type_extension

ここで、unit_name はユニットの名前を表し、type_extension はユニットタイプを特定します。ユニットファイルの詳細な一覧は 表3.2「利用可能な systemd unit タイプ」 を参照してください。たとえば、通常は、システムには sshd.service ユニットおよび sshd.socket ユニットがあります。

ユニットファイルには、追加の設定ファイルのディレクトリーを追加できます。たとえば、カスタム設定オプションを sshd.service に追加するには、sshd.service.d/custom.conf ファイルを作成し、追加のディレクティブを挿入します。設定ディレクティブの詳細情報は 「既存のユニットファイルの変更」 を参照してください。

さらに、sshd.service.wants/ ディレクトリーおよび sshd.service.requires/ ディレクトリーを作成することもできます。このディレクトリーには、sshd サービスの依存関係であるユニットファイルへのシンボリックリンクが含まれます。シンボリックリンクは、[Install] ユニットファイルに従ってインストール時に、または [Unit] オプションに基づいてランタイム時に自動的に作成されます。このディレクトリーとシンボリックリンクを手動で作成することもできます。[Install] オプションおよび [Unit] オプションの詳細は、以下の表を参照してください。

多くのユニットファイルオプションは、いわゆる ユニット指定子 を使用して設定できます。これは、ユニットファイルが読み込まれる際にユニットパラメーターに動的に置き換えられるワイルドカード文字列です。これにより、インスタンス化されるユニットを生成するためのテンプレートとして機能する汎用ユニットファイルを作成できます。詳細は 「インスタンス化されたユニットの使用」 を参照してください。

3.5.1. ユニットファイル構造の概要

通常、ユニットファイルは 3 つのセクションで構成されています。

  • [Unit] セクション- ユニットのタイプに依存しない一般的なオプションが含まれます。このセクションに含まれるオプションはユニットを説明し、ユニットの動作を指定し、他のユニットへの依存関係を設定します。[Unit] セクションで最もよく使用されるオプションの一覧は 表3.9「[Unit] セクションの重要なオプション」 を参照してください。
  • [Unit type] セクション - ユニットにタイプによる指定があれば、ユニットタイプにより命名されるセクションでグループ分けされます。たとえば、サービスユニットファイルには [Service] セクションが含まれます。
  • [Install] セクション - systemctl enable コマンドおよび disable コマンドでユニットをインストールした際の情報が含まれます。[Install] セクションの詳細は表3.11「[Install] セクションの重要なオプション」を参照してください。

表3.9 [Unit] セクションの重要なオプション

オプション[a]説明

Description

ユニットの説明です。このテキストは、たとえば systemctl status コマンドの出力に表示されます。

Documentation

ユニットのドキュメントを参照する URI の一覧を提供します。

After[b]

ユニットが開始する順序を定義します。After で指定されたユニットがアクティブになると開始します。Requires とは異なり、After は指定されたユニットを明示的にアクティブにしません。Before オプションには、After とは反対の機能があります。

Requires

他のユニットに依存関係を設定します。Requires に一覧表示されるユニットは、対応するユニットと共にアクティブになります。必要なユニットのいずれかが開始しないと、ユニットはアクティブになりません。

Wants

Requires よりも強度の弱い依存関係を設定します。一覧に示されるユニットのいずれかが正常に開始しなくても、このユニットのアクティべーションには影響を与えません。これは、カスタムのユニット依存関係を設定する際に推奨される方法です。

Conflicts

Requires と反対の依存関係 (負の依存関係) を設定します。

[a] [Unit] セクションで設定できるオプション詳細は、man ページの systemd.unit(5) を参照してください。
[b] ほとんどの場合、ユニットファイルオプションの After および Before で依存関係の並び順を設定するだけで十分です。Wants (推奨) または Requires で要件の依存関係も設定する場合、依存関係の並び順は指定する必要があります。これは、並び順と要件の依存関係が相互に依存していないためです。

表3.10 [Service] セクションの重要なオプション

オプション[a]説明

Type

ExecStart および関連オプションの機能に影響を与えるユニットプロセスの起動タイプを設定します。以下のいずれかになります。

* simple - デフォルト値です。ExecStart で起動するプロセスは、サービスのメインプロセスです。

* forking - ExecStart で起動するプロセスは、サービスのメインプロセスになる子プロセスを起動します。親プロセスは、このプロセスが完了すると終了します。

* oneshot - このタイプは simple と似ていますが、結果として生じるユニットを起動する前に終了します。

* dbus - このタイプは simple としていますが、メインプロセスが D-Bus 名を取得する前に、結果として生じるユニットが起動します。

* notify - このタイプは simple と似ていますが、結果として生じるユニットは、通知メッセージが sd_notify() 関数で送信されないと起動しません。

* idle - simple と似ていますが、サービスバイナリーの実行は、すべてのジョブが終了するまで行いません (遅らせます)。これにより、ステータスの出力とサービスのシェル出力を分けることができます。

ExecStart

ユニットの機能時に実行するコマンドまたはスクリプトを指定します。ExecStartPre および ExecStartPost は、ExecStart の前後に実行するカスタムコマンドを指定します。Type=oneshot を使用すれば、順次に実行する複数のカスタムコマンドを指定できます。

ExecStop

ユニットの停止時に実行するコマンドまたはスクリプトを指定します。

ExecReload

ユニットの再読み込み時に実行するコマンドまたはスクリプトを指定します。

Restart

このオプションを有効にすると、systemctl コマンドによる完全な停止の例外により、そのプロセスの終了後にサービスが再起動します。

RemainAfterExit

True に設定すると、サービスは、そのプロセスがすべて終了していてもアクティブと見なされます。デフォルトの値は False です。このオプションは、特に Type=oneshot が設定されている場合に役に立ちます。

[a] [Service] セクションで設定できるオプションの詳細な一覧は、man ページの systemd.service(5) を参照してください。

表3.11 [Install] セクションの重要なオプション

オプション[a]説明

Alias

ユニット名の追加一覧を、スペース区切りで提供します。systemctl enable を除くほとんどの systemctl コマンドでは、ユニット名ではなくエイリアスを使用できます。

RequiredBy

概要ユニットに依存するユニットの一覧です。このユニットが有効な場合、RequiredBy に一覧表示されるユニットは、このユニットに関する Require 依存関係を取得します。

WantedBy

このユニットへの依存が弱いユニットの一覧です。このユニットが有効な場合、 WantedBy に一覧表示されるユニットは、このユニットに関する Want 依存関係を取得します。

Also

対応するユニットと共にインストールまたはアンインストールされるユニットの一覧を指定します。

DefaultInstance

インスタンス化されているユニットだけが対象となりますが、このオプションは、ユニットが有効になっているデフォルトのインスタンスを指定します。「インスタンス化されたユニットの使用」 を参照してください。

[a] [Install] セクションで設定できるオプションは、man ページの systemd.unit(5) を参照してください。

ユニット設定を微調整するのに使用できるさまざまなオプションがあります。以下の例は、システムにインストールされているサービスユニットの例を示しています。さらに、ユニットファイルのオプションは、「インスタンス化されたユニットの使用」に説明されているように、ユニットの動的な作成が可能な方法で定義できます。

例3.16 postfix.service ユニットファイル

次に、postfix パッケージで現在提供されている /usr/lib/systemd/system/postfix.service ユニットファイルの内容が続きます。

[Unit]
Description=Postfix Mail Transport Agent
After=syslog.target network.target
Conflicts=sendmail.service exim.service

[Service]
Type=forking
PIDFile=/var/spool/postfix/pid/master.pid
EnvironmentFile=-/etc/sysconfig/network
ExecStartPre=-/usr/libexec/postfix/aliasesdb
ExecStartPre=-/usr/libexec/postfix/chroot-update
ExecStart=/usr/sbin/postfix start
ExecReload=/usr/sbin/postfix reload
ExecStop=/usr/sbin/postfix stop

[Install]
WantedBy=multi-user.target

[Unit] セクションでは、サービスについて説明し、競合するユニットおよび並び順依存関係を指定します。[Service] では、カスタムスクリプトのシーケンスが、ユニットのアクティべーション時、停止時、および再読み込み時に実行するように指定します。EnvironmentFile は、サービスの環境変数が定義されるロケーションを参照し、PIDFile はサービスのメインプロセスの安定した PID を指定します。最後に、[Install] セクションはサービスに依存するユニットを一覧表示します。

3.5.2. カスタムユニットファイルの作成

ユニットファイルをゼロから作成するための複数のユースケースがあります。カスタムデーモンを実行したり、(「sshd サービスの 2 つ目のインスタンスの作成」に説明されているように) 一部の既存サービスの 2 つ目のインスタンスを作成したり、SysV init スクリプトをインポート (詳細は「SysV Init スクリプトのユニットファイルへの変換」を参照) できます。一方、既存ユニットの動作の変更または拡張のみを実行しようとする場合は、「既存のユニットファイルの変更」の指示に従ってください。以下の手順では、カスタムサービスを作成する一般的なプロセスを説明します。

  1. カスタムサービスで実行可能なファイルを用意します。カスタムで作成されたスクリプトや、ソフトウェアプロバイダーが提供する実行可能ファイルがこれにあたります。必要な場合は、カスタムサービスのメインプロセスの PID を保持するため、PID ファイルを用意します。また、サービスのシェル変数を保存するために環境ファイルを組み込むこともできます。ソーススクリプトが (chmod a+x を実行して) 実行可能であり、インタラクティブではないことを確認してください。
  2. /etc/systemd/system/ ディレクトリーにユニットファイルを作成し、適切なファイルアクセス権があることを確認します。root で次のコマンドを実行します。

    touch /etc/systemd/system/name.service
    
    chmod 664 /etc/systemd/system/name.service

    name を、作成するサービスの名前に置き換えます。ファイルには実行権限は必要ありません。

  3. 上で作成した name.service ファイルを開き、サービス設定オプションを追加します。作成するサービスのタイプに応じて、さまざまなオプションを使用できます。「ユニットファイル構造の概要」 を参照してください。以下は、ネットワーク関連サービスのユニットの設定例になります。

    [Unit]
    Description=service_description
    After=network.target
    
    [Service]
    ExecStart=path_to_executable
    Type=forking
    PIDFile=path_to_pidfile
    
    [Install]
    WantedBy=default.target

    ここで、

    • service_description は、ジャーナルログファイルおよび systemctl status コマンドの出力に表示される役立つ説明です。
    • After 設定により、このサービスは、ネットワークが実行してから起動します。関連するサービスまたはターゲットは、スペースで区切って追加します。
    • path_to_executable は、サービス実行可能ファイルへのパスを表します。
    • Type=forking は、fork システム呼び出しを行うデーモンに使用します。サービスのメインプロセスは、path_to_pidfile で指定した PID で作成されます。その他の起動タイプは、表3.10「[Service] セクションの重要なオプション」 を参照してください。
    • WantedBy では、サービスを起動するターゲットを指定します。ターゲットは、従来のランレベルの代替と見なすことができます。詳細は 「systemd ターゲットでの作業」 を参照してください。
  4. root で以下のコマンドを実行すると、新しい name.service ファイルが存在することが systemd に通知します。

    systemctl daemon-reload
    
    systemctl start name.service
    警告

    新しいユニットファイルを作成したり、既存のユニットファイルを修正したら常に systemctl daemon-reload コマンドを実行します。このコマンドを実行しないと、systemd のステータスと、ディスクの実際のサービスユニットファイルが一致しなくなるため、systemctl start コマンドや systemctl enable コマンドが失敗します。システムにユニットが多数と、各ユニットの状態をシリアライズし、その後再起動時にデシリアライズするため時間がかかります。

例3.17 emacs.service ファイルの作成

Emacs テキストエディターを使用する場合は、ファイルの編集時にプログラムの新規インスタンスを起動するよりも、バックグラウンドで実行する方がスピードが速いため便利です。以下の手順では、Emacs のユニットファイルを作成し、これをサービスのように処理する方法を説明します。

  1. /etc/systemd/system/ ディレクトリーにユニットファイルを作成し、ファイルパーミッションが正しいことを確認してください。root で以下のコマンドを実行します。

    ~]# touch /etc/systemd/system/emacs.service
    ~]# chmod 664 /etc/systemd/system/emacs.service
  2. 以下の内容をファイルに追加します。

    [Unit]
    Description=Emacs: the extensible, self-documenting text editor
    
    [Service]
    Type=forking
    ExecStart=/usr/bin/emacs --daemon
    ExecStop=/usr/bin/emacsclient --eval "(kill-emacs)"
    Environment=SSH_AUTH_SOCK=%t/keyring/ssh
    Restart=always
    
    [Install]
    WantedBy=default.target

    上記の設定では、サービスの起動時に、/usr/bin/emacs 実行可能ファイルがデーモンモードで開始します。SSH_AUTH_SOCK 環境変数は、ランタイムディレクトリーを表す "%t" ユニット指定子で設定されます。また、このサービスは、emacs プロセスが予期せずに終了した場合はこれを再起動します。

  3. 以下のコマンドを実行して、設定の再読み込みを行い、カスタムサービスを起動します。

    ~]# systemctl daemon-reload
    ~]# systemctl start emacs.service

これでエディターは systemd サービスとして登録されるため、標準的な systemctl コマンドがすべて使用できます。たとえば、systemctl status emacs でエディターのステータスを表示したり、systemctl enable emacs でシステム起動時にエディターを自動的に起動したりできます。

例3.18 sshd サービスの 2 つ目のインスタンスの作成

システム管理者は、サービスのインスタンスを複数設定し、実行しなければならないことが多々あります。これは、サービスの主なインスタンスとの競合を避けるために、元のサービス設定ファイルのコピーを作成し、特定のパラメーターを変更することで実行します。以下の手順は、sshd サービスの 2 つ目のインスタンスを作成する方法を示しています。

  1. 2 つ目のデーモンで使用する、sshd_config ファイルのコピーを作成します。

    ~]# cp /etc/ssh/sshd{,-second}_config
  2. 作成した sshd-second_config ファイルを編集し、2 つ目のデーモンに別のポート番号と PID ファイルを割り当てます。

    Port 22220
    PidFile /var/run/sshd-second.pid

    Port オプションおよび PidFile オプションの詳細は、man ページの sshd_config(5) を参照してください。他のサービスで使用されていないポートを選択してください。PID ファイルはサービスの実行時に存在していなければいけないものではありません。存在しない場合は、サービスの起動時に自動的に生成されます。

  3. sshd サービスの systemd ユニットファイルのコピーを作成します。

    ~]# cp /usr/lib/systemd/system/sshd.service /etc/systemd/system/sshd-second.service
  4. 作成した sshd-second.service を以下のように変更します。

    1. Description オプションを変更します。

      Description=OpenSSH server second instance daemon
    2. After オプションを指定するサービスに sshd.service を追加し、最初のインスタンスが起動した場合に限り 2 つ目のインスタンスが起動するようにします。

      After=syslog.target network.target auditd.service sshd.service
    3. sshd の最初のインスタンスには鍵の生成が含まれるため、ExecStartPre=/usr/sbin/sshd-keygen 行を削除します。
    4. sshd コマンドに -f /etc/ssh/sshd-second_config パラメーターを追加して、代替の設定ファイルが使用されるようにします。

      ExecStart=/usr/sbin/sshd -D -f /etc/ssh/sshd-second_config $OPTIONS
    5. 上記のように変更すると、sshd-second.service は以下のようになります。

      [Unit]
      Description=OpenSSH server second instance daemon
      After=syslog.target network.target auditd.service sshd.service
      
      [Service]
      EnvironmentFile=/etc/sysconfig/sshd
      ExecStart=/usr/sbin/sshd -D -f /etc/ssh/sshd-second_config $OPTIONS
      ExecReload=/bin/kill -HUP $MAINPID
      KillMode=process
      Restart=on-failure
      RestartSec=42s
      
      [Install]
      WantedBy=multi-user.target
  5. SELinux を使用している場合は、sshd の 2 番目のインスタンスのポートを SSH ポートに追加します。追加しないと、sshd の 2 番目のインスタンスがポートにバインドされません。

    ~]# semanage port -a -t ssh_port_t -p tcp 22220
  6. システムの起動時にこのサービスが自動的に起動するように、sshd-second.service を有効にします。

    ~]# systemctl enable sshd-second.service

    systemctl status コマンドを使用して sshd-second.service が実行中かどうかを確認します。さらに、ポートをサービスに接続して、適切に有効になっているかどうかを確認します。

    ~]$ ssh -p 22220 user@server

    ファイアウォールを使用している場合は、sshd の 2 番目のインスタンスへの接続を許可するように適切に設定されていることを確認してください。

カスタムユニットファイルの並び順および依存関係のターゲットを適切に選択する方法は、以下の Red Hat ナレッジベースの記事を参照してください。

ユニットファイルの並び順および依存関係に関する実例と追加情報は「Is there any useful information about writing unit files?」を参照してください。

systemd が開始するサービスへの制限の設定は、Red Hat ナレッジベースの記事 「RHEL 7 および systemd でサービスに制限を設定する 」 を参照してください。この制限は、サービスのユニットファイルで設定する必要があります。systemd は、/etc/security/limits.conf 設定ファイルおよび /etc/security/limits.d/*.conf 設定ファイルに設定した制限を無視する点に注意してください。このファイルに定義した制限は、ログインセッションの開始時に PAM により設定されますが、systemd が開始するデーモンは、PAM ログインセッションを使用しません。

3.5.3. SysV Init スクリプトのユニットファイルへの変換

SysV init スクリプトをユニットファイルに変換する前に、すでに別の場所で変換が行われていないことを確認します。Red Hat Enterprise Linux にインストールされるすべてのコアサービスにデフォルトのユニットファイルが同梱されていますが、数多くのサードパーティーソフトウェアパッケージにも同様のことが言えます。

init スクリプトをユニットファイルに変換するには、スクリプトを分析し、そこから必要な情報を抽出することが必要になります。このデータに基づいて、ユニットファイルを作成できます。init スクリプトはサービスのタイプによって大幅に異なるため、この章で概略されているよりも多くの設定オプションの変換を使用しなければならない場合もあります。init スクリプトで利用できるカスタマイズの一部のレベルが systemd ユニットでサポートされなくなっていることに注意してください。

変換に必要とされるほとんどの情報はスクリプトのヘッダーに提供されます。以下の例は、Red Hat Enterprise Linux 6 で postfix サービスを起動するために使用される init スクリプトの開始セクションになります。

!/bin/bash # postfix Postfix Mail Transfer Agent # chkconfig: 2345 80 30 # description: Postfix is a Mail Transport Agent, which is the program that moves mail from one machine to another. # processname: master # pidfile: /var/spool/postfix/pid/master.pid # config: /etc/postfix/main.cf # config: /etc/postfix/master.cf  BEGIN INIT INFO # Provides: postfix MTA # Required-Start: $local_fs $network $remote_fs # Required-Stop: $local_fs $network $remote_fs # Default-Start: 2 3 4 5 # Default-Stop: 0 1 6 # Short-Description: start and stop postfix # Description: Postfix is a Mail Transport Agent, which is the program that moves mail from one machine to another. # END INIT INFO

上記の例では、# chkconfig および # description で始まる行のみが必須になり、init ファイルによってはその他の記載はない可能性もあります。BEGIN INIT INFO 行と END INIT INFO 行に囲まれたテキストは Linux Standard Base (LSB) ヘッダー と呼ばれています。LSB ヘッダーを指定している場合は、サービスの説明、依存関係、およびデフォルトのランレベルを定義するディレクティブがこれに含まれます。次に、新規のユニットファイルに必要なデータを収集する分析タスクの概要が続きます。postfix init スクリプトはサンプルとして使用されます。作成される postfix ユニットは 例3.16「postfix.service ユニットファイル」 を参照してください。

サービス説明の検索

#description で始まる行で、スクリプトに関する説明情報を確認します。この説明は、サービス名と共に、ユニットファイルの [Unit] セクションの Description オプションで使用します。LSB ヘッダーの #Short-Description 行および #Description 行に同様のデータが含まれる場合があります。

サービス依存関係の検索

LSB ヘッダーには、サービス間の依存関係を形成する複数のディレクティブが含まれる場合があります。そのほとんどは systemd ユニットオプションに変換できます。表3.12「LSB ヘッダーの依存関係オプション」 を参照してください。

表3.12 LSB ヘッダーの依存関係オプション

LSB オプション説明同等のユニットファイル

Provides

サービスの起動ファシリティー名を指定します。この名前は他の init スクリプトで参照できます ( "$" 接頭辞を使用)。ただし、ユニットファイルが他のユニットをファイル名で参照できるようになったため、これは不要になりました。

Required-Start

必要なサービスの起動ファシリティー名が含まれます。これは、並び順依存関係として変換され、起動ファシリティー名は、対応するサービスまたはそのサービスが属するターゲットに置き換えられます。たとえば、postfix の場合、$network の Required-Start 依存関係は、network.target の After 依存関係に変換されました。

AfterBefore

Should-Start

Required-Start よりも弱い依存関係を構成します。Should-Start 依存関係が失敗しても、サービスの起動には影響を及ぼしません。

AfterBefore

Required-StopShould-Stop

負の依存関係を構成します。

Conflicts

サービスのデフォルトターゲットの検索

#chkconfig で始まる行には 3 つの数値があります。最も重要な値は最初の数値で、サービスが起動するデフォルトのランレベルを示しています。ランレベルは、同等の systemd ターゲットに対応します。次に、そのターゲットを、ユニットファイルの [Install] セクションの WantedBy オプションに記述します。たとえば、postfix がランレベルの 2、3、4、および 5 で起動していた場合、これは multi-user.target および graphical.target に対応します。ただし、graphical.target は multiuser.target に依存するため、例3.16「postfix.service ユニットファイル」 の説明にあるように、両方を記述する必要はありません。また、LSB ヘッダーの #Default-Start 行および #Default-Stop 行に、デフォルト、および動作するべきでないランレベルの情報がある場合は、そちらも参照してください。

#chkconfig 行で指定した他の 2 つの値は、init スクリプトの起動およびシャットダウンの優先順位を表します。この値は、init スクリプトが読み込まれる場合は systemd によって解釈されますが、同等のユニットファイルはありません。

サービスで使用されるファイルの検索

init スクリプトでは、専用ディレクトリーから機能ライブラリーを読み込み、設定ファイル、環境ファイル、および PID ファイルのインポートを許可します。環境変数は init スクリプトヘッダーの #config で始まる行で指定し、EnvironmentFile ユニットファイルオプションに変換されます。#pidfile init スクリプト行に指定した PID ファイルは、PIDFile オプションでユニットファイルにインポートされます。

init スクリプトヘッダーに含まれない主要な情報は、サービス実行可能ファイルへのパス、またはサービスで必要になる可能性のあるその他のファイルへのパスです。以前のバージョンの Red Hat Enterprise Linux では、init スクリプトは、カスタム定義のアクションと共に 起動停止再起動 などのデフォルトアクションのサービスの動作を定義するために Bash ケースステートメントを使用しました。postfix init スクリプトからの以下の抜粋は、サービス起動時に実行されるコードのブロックを示しています。

conf_check() {
    [ -x /usr/sbin/postfix ] || exit 5
    [ -d /etc/postfix ] || exit 6
    [ -d /var/spool/postfix ] || exit 5
}

make_aliasesdb() {
	if [ "$(/usr/sbin/postconf -h alias_database)" == "hash:/etc/aliases" ]
	then
		# /etc/aliases.db might be used by other MTA, make sure nothing
		# has touched it since our last newaliases call
		[ /etc/aliases -nt /etc/aliases.db ] ||
			[ "$ALIASESDB_STAMP" -nt /etc/aliases.db ] ||
			[ "$ALIASESDB_STAMP" -ot /etc/aliases.db ] || return
		/usr/bin/newaliases
		touch -r /etc/aliases.db "$ALIASESDB_STAMP"
	else
		/usr/bin/newaliases
	fi
}

start() {
	[ "$EUID" != "0" ] && exit 4
	# Check that networking is up.
	[ ${NETWORKING} = "no" ] && exit 1
	conf_check
	# Start daemons.
	echo -n $"Starting postfix: "
	make_aliasesdb >/dev/null 2>&1
	[ -x $CHROOT_UPDATE ] && $CHROOT_UPDATE
	/usr/sbin/postfix start 2>/dev/null 1>&2 && success || failure $"$prog start"
	RETVAL=$?
	[ $RETVAL -eq 0 ] && touch $lockfile
        echo
	return $RETVAL
}

init スクリプトの拡張性により、start() 関数ブロックから呼び出される conf_check() および make_aliasesdb() の 2 つのカスタム関数を指定することができました。さらに詳しくみると、上記コードでは外部のファイルおよびディレクトリーが複数記述されています (主なサービス実行可能ファイル /usr/sbin/postfix、設定ディレクトリー /etc/postfix//var/spool/postfix/、および /usr/sbin/postconf/ ディレクトリー) 。

Systemd は、事前に定義されたアクションのみをサポートしますが、オプションの ExecStartExecStartPreExecStartPostExecStop、および ExecReload でカスタムの実行ファイルを有効にできます、/usr/sbin/postfix はサポートスクリプトとともに、サービスの起動時に実行されます。postfix ユニットファイルは 例3.16「postfix.service ユニットファイル」 を参照してください。

複雑な init スクリプトを変換する際には、スクリプトのすべてのステートメントの目的を理解している必要があります。一部のステートメントはオペレーティングシステムのバージョンに固有のものであるため、そのステートメントを systemd 用に変換する必要はありません。一方、新規の環境では、サービス実行可能ファイルおよびサポートファイルやユニットファイルで調整が一部必要となる場合があります。

3.5.4. 既存のユニットファイルの変更

システムにインストールされるサービスは、/usr/lib/systemd/system/ ディレクトリーに保存されるデフォルトのユニットファイルと共に提供されます。システム管理者はこのファイルを直接変更できないため、カスタマイズは /etc/systemd/system/ ディレクトリーの設定ファイルに制限される必要があります。必要とされる変更の程度に応じて、以下の方法のいずれかを実施してください。

  • 補助設定ファイルのディレクトリーを /etc/systemd/system/unit.d/ に作成します。この方法は、ほとんどのユースケースで推奨されます。これにより、元のユニットファイルを参照しつつも、デフォルト設定を追加の機能で拡張できます。この場合、パッケージのアップグレードで導入されるデフォルトユニットへの変更は自動的に適用されます。詳細は 「デフォルトのユニット設定の拡張」 を参照してください。
  • 元のユニットファイル /usr/lib/systemd/system/ のコピーを /etc/systemd/system/ に作成し、そこで変更を行います。コピーは元のファイルを上書きするため、パッケージの更新で導入される変更は適用されません。この方法は、パッケージの更新とは無関係に永続する重要なユニット変更を行う際に役に立ちます。詳細は 「Overriding the default unit configuration」 を参照してください。

ユニットのデフォルト設定に戻るには、/etc/systemd/system/ でカスタム作成した設定ファイルを削除します。システムを再起動せずにユニットファイルへの変更を適用するには、以下を実行します。

systemctl daemon-reload

daemon-reload オプションは、すべてのユニットファイルを再読み込みし、ユニットファイルへの変更をすぐに適用するために必要な依存関係ツリー全体を再作成します。また、以下のコマンドを使用しても同じ結果になります。実行する際に root ユーザーになる必要があります。

init q

変更したユニットファイルが実行中のサービスに属する場合は、このサービスを再起動して新たな設定を反映させる必要があります。

systemctl restart name.service
重要

SysV init スクリプトが処理しているサービスのプロパティ (依存関係やタイムアウトなど) を変更するときは、init スクリプト自体は変更しないでください。代わりに、「Extending the default unit configuration」「Overriding the default unit configuration」 にあるように、サービスの systemd ドロップイン設定ファイルを作成します。その後、通常の systemd サービスと同じ方法でサービスを管理します。

たとえば、network サービスの設定を拡張するときは、init スクリプトファイル /etc/rc.d/init.d/network を変更しないでください。代わりに、新しいディレクトリー /etc/systemd/system/network.service.d/ と、systemd ドロップインファイル /etc/systemd/system/network.service.d/my_config.conf を作成します。そして、ドロップインファイルの値を変更します。systemd は、network サービスを network.service として認識することに注意してください。作成したディレクトリーが network.service.d と命名されるのはそのためです。

デフォルトのユニット設定の拡張

追加の設定オプションでデフォルトのユニットファイルを拡張するには、最初に /etc/systemd/system/ に設定ディレクトリーを作成します。サービスユニットを拡張する場合は、root で以下のコマンドを実行します。

mkdir /etc/systemd/system/name.service.d/

name を、拡張する必要のあるサービス名に置き換えます。上記の構文はすべてのユニットタイプに適用されます。

作成したディレクトリーに設定ファイルを作成します。ファイル名の接尾辞は .conf にする必要があることに注意してください。以下のコマンドを実行します。

touch /etc/systemd/system/name.service.d/config_name.conf

config_name を、設定ファイルの名前に置き換えます。このファイルは、通常のユニットファイル構造に基づくため、すべてのディレクティブは該当するセクションで指定する必要があります。「ユニットファイル構造の概要」 を参照してください。

たとえば、カスタムの依存性を追加するには、以下の内容で設定ファイルを作成します。

[Unit]
Requires=new_dependency
After=new_dependency

ここで、new_dependency は依存性としてマークが付けられるユニットを表します。次の例は、30 秒の遅延後のメインプロセス終了後にサービスを再起動する設定ファイルです。

[Service]
Restart=always
RestartSec=30

1 つのタスクだけを扱う簡単な設定ファイルを作成することが推奨されます。これにより、他のサービスの設定ディレクトリーに簡単に移動したり、リンクします。

そのユニットに行った変更を適用するには、root で以下のコマンドを実行します。

systemctl daemon-reload
systemctl restart name.service

例3.19 httpd.service 設定の拡張

Apache サービスの起動時にカスタムシェルスクリプトが自動的に実行されるように httpd.service ユニットを変更するには、以下の手順で行います。まず、ディレクトリーおよびカスタム設定ファイルを作成します。

~]# mkdir /etc/systemd/system/httpd.service.d/
~]# touch /etc/systemd/system/httpd.service.d/custom_script.conf

Apache で自動的に起動するスクリプトが /usr/local/bin/custom.sh にある場合は、以下のテキストを custom_script.conf ファイルに挿入します。

[Service]
ExecStartPost=/usr/local/bin/custom.sh

ユニットの変更を適用するには、以下を実行します。

~]# systemctl daemon-reload
~]# systemctl restart httpd.service
注記

/etc/systemd/system/ の設定ディレクトリーの設定ファイルは、/usr/lib/systemd/system/ のユニットファイルに優先します。そのため、設定ファイルに、1 回だけ指定できるオプション (DescriptionExecStart など) が含まれる場合は、このオプションのデフォルト値が上書きされます。「Monitoring overriden units」 で説明されているように、systemd-delta コマンドの出力では、一部のオプションは実際に上書きされますが、該当のユニットは常に [EXTENDED] とマークされます。

デフォルトのユニット設定の上書き

ユニットファイルを提供するパッケージの更新後も変更を持続させるには、最初にファイルを /etc/systemd/system/ ディレクトリーにファイルをコピーします。それを行うには、root で以下のコマンドを実行します。

cp /usr/lib/systemd/system/name.service /etc/systemd/system/name.service

name は、変更するサービスユニットの名前を表します。上記の構文はすべてのユニットタイプに適用されます。

コピーされたファイルをテキストエディターで開き、必要な変更を行います。ユニットの変更を適用するには、root で以下を実行します。

systemctl daemon-reload
systemctl restart name.service

例3.20 タイムアウト制限の変更

サービスごとにタイムアウト値を指定すると、正常に動作していないサービスによってシステムがフリーズすることを防ぐことができます。タイムアウト値を指定しないサービスには、通常のサービスの場合は 90 秒、そして SysV と互換性のあるサービスの場合は 300 秒と、それぞれデフォルトのタイムアウトが設定されます。

たとえば、httpd サービスのタイムアウト制限を延長するときは、以下を行います。

  1. httpd ユニットファイルを、/etc/systemd/system/ ディレクトリーにコピーします。

    cp /usr/lib/systemd/system/httpd.service /etc/systemd/system/httpd.service
  2. /etc/systemd/system/httpd.service ファイルを開き、[Service] セクションに TimeoutStartSec 値を指定します。

    …​
    [Service]
    …​
    PrivateTmp=true
    TimeoutStartSec=10
    
    [Install]
    WantedBy=multi-user.target
    …​
  3. systemd デーモンを再ロードします。

    systemctl daemon-reload
  4. 任意で、新しいタイムアウト値を確認します。

    systemctl show httpd -p TimeoutStartUSec
注記

グローバルでタイムアウト制限を変更するには、/etc/systemd/system.conf ファイルの DefaultTimeoutStartSec を変更します。

上書きされたユニットのモニタリング

上書きされたか、または変更されたユニットファイルの概要を表示するには、以下のコマンドを使用します。

systemd-delta

上記のコマンドを実行すると、以下のような出力になります。

[EQUIVALENT] /etc/systemd/system/default.target → /usr/lib/systemd/system/default.target
[OVERRIDDEN] /etc/systemd/system/autofs.service → /usr/lib/systemd/system/autofs.service

--- /usr/lib/systemd/system/autofs.service      2014-10-16 21:30:39.000000000 -0400
+ /etc/systemd/system/autofs.service  2014-11-21 10:00:58.513568275 -0500
@@ -8,7 +8,8 @@
 EnvironmentFile=-/etc/sysconfig/autofs
 ExecStart=/usr/sbin/automount $OPTIONS --pid-file /run/autofs.pid
 ExecReload=/usr/bin/kill -HUP $MAINPID
-TimeoutSec=180
+TimeoutSec=240
+Restart=Always

 [Install]
 WantedBy=multi-user.target

[MASKED]     /etc/systemd/system/cups.service → /usr/lib/systemd/system/cups.service
[EXTENDED]   /usr/lib/systemd/system/sssd.service → /etc/systemd/system/sssd.service.d/journal.conf

4 overridden configuration files found.

表3.13「systemd-delta の相違タイプ」 は、systemd-delta の出力で表示される上書きタイプを一覧表示します。ファイルが上書きされた場合は、デフォルトで systemd-delta が、diff コマンドの出力に似た変更の要約を表示します。

表3.13 systemd-delta の相違タイプ

タイプ説明

[MASKED]

マスクされたユニットファイルです。ユニットマスクの説明は 「サービスの無効化」 を参照してください。

[EQUIVALENT]

元のファイルを上書きしますが、コンテンツは変更されていないコピーです。通常はシンボリックリンクです。

[REDIRECTED]

別のファイルにリダイレクトされるファイルです。

[OVERRIDEN]

上書きされ、変更されたファイルです。

[EXTENDED]

/etc/systemd/system/unit.d/ ディレクトリーの .conf ファイルで拡張されているファイルです。

[UNCHANGED]

--type=unchanged オプションが使用される場合にのみ表示される、変更されていないファイルです。

システムの更新後に、systemd-delta を実行して、デフォルトユニットに対してカスタム設定で上書きした更新があるかどうかを確認できます。さらに、出力する更新を、特定のタイプに制限することもできます。たとえば、上書きされたユニットのみを表示するには、以下のコマンドを実行します。

systemd-delta --type=overridden

ユニットファイルを編集し、送信した変更でドロップインファイルを自動的に作成するには、以下のコマンドを使用します。

~]# systemctl edit unit_name.type_extension

オーバーライド、およびドロップインをすべて適用するユニット設定をダンプするには、以下のコマンドを使用します。

~]# systemctl cat unit_name.type_extension

unit_name.type_extension を、必要なユニット名と、そのタイプ (たとえば tuned.service) に置き換えます。

3.5.5. インスタンス化されたユニットの使用

ランタイム時に、1 つのテンプレート設定ファイルから複数のユニットをインスタンス化できます。「@」文字は、テンプレートにマークを付け、ユニットをこれに関連付けるために使用されます。インスタンス化されたユニットは、( Requires オプションまたは Wants オプションを使用して) 別のユニットから開始することも、systemctl start コマンドで開始することもできます。インスタンス化されたサービスユニットの名前は以下のような形式となります。

template_name@instance_name.service

ここで、template_name は、テンプレート設定ファイルの名前になります。instance_name を、ユニットインスタンスの名前に置き換えます。複数のインスタンスが同じテンプレートを参照し、このテンプレートには、ユニットの全インスタンスに共通の設定オプションが含まれます。テンプレートユニットの名前には以下の形式が使用されます。

unit_name@.service

たとえば、ユニットファイルに次の Wants 設定を指定すると、

Wants=getty@ttyA.service getty@ttyB.service

この設定により、systemd が、最初に指定したサービスユニットを検索します。該当するユニットが見つからないと、「@」とタイプ接尾辞の間にある部分は無視され、getty@.service ファイルを検索し、そこから設定を読み取り、サービスを起動します。

ワイルドカード文字 (ユニット指定子 とも呼ばれる) をすべてのユニット設定ファイルで使用できます。ユニット指定子は、ランタイム時に特定のユニットパラメーターに置き換えて解釈されます。表3.14「重要なユニット指定子」 で、特にテンプレートユニットで役に立つユニット指定子の一覧を紹介します。

表3.14 重要なユニット指定子

ユニット指定子意味説明

%n

完全ユニット名

タイプ接尾辞を含む完全ユニット名を表します。%N には同じ意味がありますが、禁止文字を ASCII コードに置き換えます。

%p

接頭辞名

タイプ接尾辞が削除されたユニット名を表します。インスタンス化されたユニットの %p は、ユニット名の「@」文字の前の部分を表します。

%i

インスタンス名

インスタンス化されたユニット名の「@」文字およびタイプ接尾辞間の部分です。%I には同じ意味がありますが、禁止文字を ASCII コードにも置き換えます。

%H

ホスト名

ユニット設定が読み込まれる時点の実行中システムのホスト名を表します。

%t

ランタイムディレクトリー

ランタイムディレクトリーを表します。これは、root ユーザーの /run、または非特権ユーザー XDG_RUNTIME_DIR 変数になります。

ユニット指定子の詳細な一覧は、man ページの systemd.unit(5) を参照してください。

たとえば、 getty@.service テンプレートには以下のディレクティブが含まれます。

[Unit]
Description=Getty on %I
…​
[Service]
ExecStart=-/sbin/agetty --noclear %I $TERM
…​

上記のテンプレートから getty@ttyA.service および getty@ttyB.service をインスタンス化する場合、Description= は Getty on ttyA および Getty on ttyB として解決されます。

3.6. 関連資料

systemd と、Red Hat Enterprise Linux での使用方法は、以下に挙げる資料を参照してください。

3.6.1. インストールされているドキュメント

  • systemctl(1) - systemctl コマンドラインユーティリティーの man ページでは、サポートされるオプションとコマンドの完全なリストが提供されます。
  • systemd(1) - systemd システムおよびサービスマネージャーの man ページでは、その概念に関する詳細情報が提供され、利用可能なコマンドラインオプションと環境変数、サポートされる設定ファイルとディレクトリー、認識されるシグナル、および利用可能なカーネルオプションが説明されています。
  • systemd-delta(1) - 拡張され、上書きされた設定ファイルの検索を可能にする systemd-delta ユーティリティーの man ページです。
  • systemd.directives(7) - systemd.directives という名前の man ページは、systemd ディレクティブの詳細が提供されます。
  • systemd.unit(5) - systemd.unit の man ページでは、systemd ユニットファイルの詳細情報と、利用可能なすべての設定オプションが説明されてます。
  • systemd.service(5) - systemd.service の man ページは、サービスユニットファイルの形式が紹介されています。
  • systemd.target(5) - systemd.target の man ページには、ターゲットユニットファイルの形式が説明されています。
  • systemd.kill(5) - systemd.kill の man ページでは、プロセスの強制終了手順の設定が説明されています。

3.6.2. オンラインのドキュメント

  • systemd ホームページ - このプロジェクトのホームページでは、systemd に関する詳細情報が提供されています。

3.7. 起動時間を短縮するための systemd の最適化

デフォルトで有効になっている systemd ユニットファイルの一覧があります。システムの起動時に、このようなユニットファイルで定義されているシステムサービスが自動的に実行し、システムの起動時間に影響を及ぼします。

このセクションでは、以下について説明します。

  • システムの起動パフォーマンスを調べるツール
  • systemd ユニットがデフォルトで無効になっている目的と、起動時間を短縮するために、このような systemd ユニットを安全に無効にする状況

3.7.1. システムの起動パフォーマンスの調査

システムブートのパフォーマンスを調べるためには、systemd-analyze コマンドを使用できます。このコマンドでは、多数のオプションが使用できますが、本セクションでは、起動時間を短縮するために、systemd の調整の点で重要になるものだけを説明します。

オプションの完全リストおよび詳細な説明は、man ページの systemd-analyze を参照してください。

前提条件

システムの起動時に調整するために、systemd を調べ始める前に、有効なサービスの一覧を表示することもできます。

~]$ systemctl list-unit-files --state=enabled
システム全体の起動時間の分析
手順
  • システムが最後に起動してからの時間に関する総合的な情報を表示するには、次のコマンドを実行します。
~]$ systemd-analyze
ユニットの初期化時間の分析
手順
  • 各 systemd ユニットの初期化時間の詳細を確認するには、次のコマンドを実行します。
~]$ systemd-analyze blame

この出力では、システムが最後に起動した時に初期化にかかった時間に応じて、ユニットが降順で表示されます。

重要なユニットの識別
手順
  • システムが最後に起動した時に、初期化に最も時間がかかったユニットを特定するには、次のコマンドを実行します。
~]$ systemd-analyze critical-chain

この出力では、起動に非常に時間がかかっているユニットが、赤字で強調表示されています。

図3.1 systemd-analyze critical-chain コマンドの出力

systemd analyze critical

3.7.2. 安全に無効にできるサービスを選択するためのガイド

システムの起動時に時間がかかっている場合は、デフォルトで起動時に有効になっているサービスの一部を無効にすることで、起動時間を短くできます。

このようなサービスを一覧表示するには、次のコマンドを実行します。

~]$ systemctl list-unit-files --state=enabled

サービスを無効にするには、次のコマンドを実行します。

~]# systemctl disable service_name

ただし、お使いのオペレーティングシステムが安全で、希望通りに機能できるように、特定のサービスは有効にしたままにしておく必要があります。

次の表は、安全に無効にできるサービスを選択するためのガイドとして使用できます。この表では、Red Hat Enterprise Linux 8 の最小インストールで、デフォルトで有効になっているすべてのサービスと、各サービスを安全に無効にできるかどうかを説明します。

その他にも、サービスを無効にできる状況と、そのサービスを無効にすべきではない理由を示しています。

表3.15 RHEL 8 の最小インストールで、デフォルトで有効になっているサービス

サービス名無効にすることはできますか?詳細情報

auditd.service

yes

auditd.service は、カーネルからの監査メッセージが必要ない場合に限り無効にします。auditd.service を無効にすると、/var/log/audit/audit.log ファイルが生成されないことに注意してください。これにより、ユーザーログイン、サービスの起動、パスワードの変更などの、一般的に確認されるアクションまたはレビューをさかのぼって確認することはできません。auditd には、カーネルの部分と、サービスそのものが含まれることに注意してください。systemctl disable auditd コマンドを実行すると、サービスを無効にするだけで、カーネル部分は無効にしません。システムの監査を完全に無効にするには、カーネルのコマンドラインに audit=0 と設定します。

autovt@.service

no

このサービスは、それが本当に必要な場合に限り実行されるため、無効にする必要はありません。

crond.service

yes

crond.service を無効にすると crontab からアイテムが実行しないことに注意してください。

dbus-org.fedoraproject.FirewallD1.service

yes

firewalld.service へのシンボリックリンク

dbus-org.freedesktop.NetworkManager.service

yes

NetworkManager.service へのシンボリックリンク

dbus-org.freedesktop.nm-dispatcher.service

yes

NetworkManager-dispatcher.service へのシンボリックリンク

firewalld.service

yes

ファイアウォールが必要ない場合に限り firewalld.service を無効にします。

getty@.service

no

このサービスは、それが本当に必要な場合に限り実行されるため、無効にする必要はありません。

import-state.service

yes

import-state.service は、ネットワークストレージからの起動が必要ない場合に限り無効にします。

irqbalance.service

yes

irqbalance.service は、CPU が 1 つしかない場合に限り無効にします。システムに CPU が複数ある場合は irqbalance.service を無効にしないでください。

kdump.service

yes

kdump.service は、カーネルクラッシュからのレポートが必要ない場合に限り無効にします。

loadmodules.service

yes

このサービスは、/etc/rc.modules ディレクトリーまたは /etc/sysconfig/modules ディレクトリーがなければ起動しません。つまり、RHEL 8 の最小インストールでは起動しません。

lvm2-monitor.service

yes

lvm2-monitor.service は、論理ボリュームマネージャー (LVM) を使用しない場合に限り無効にします。

microcode.service

no

そのサービスは、CPU 内のマイクロコードソフトウェアの更新を提供するため、無効にしないでください。

NetworkManager-dispatcher.service

yes

NetworkManager-dispatcher.service は、ネットワーク設定変更の通知が必要ない場合 (静的ネットワークなど) に限り無効にします。

NetworkManager-wait-online.service

yes

NetworkManager-wait-online.service は、システムの起動直後にネットワーク接続が利用できるようになっている必要がない場合に限り無効にします。このサービスを有効にすると、ネットワーク接続が有効になるまで、システムの起動が完了しません。これにより、起動時間が大幅に長くなることがあります。

NetworkManager.service

yes

NetworkManager.service は、ネットワークへの接続が必要ない場合に限り無効にします。

nis-domainname.service

yes

nis-domainname.service は、ネットワークインフォメーションサービス (NIS) を使用しない場合に限り無効にします。

rhsmcertd.service

no

 

rngd.service

yes

rngd.service は、お使いのシステムでエントロピーが多数必要ない場合、またはハードウェアジェネレーターがない場合に限り無効にします。このサービスは、X.509 証明書の生成に使用されるシステム (たとえば FreeIPA サーバー) など、良好なエントロピーを多数必要とする環境で必要になります。

rsyslog.service

yes

rsyslog.service は、永続的なログが必要ない場合に限り、または systemd-journald を永続モードに設定した場合に限り無効にします。

selinux-autorelabel-mark.service

yes

selinux-autorelabel-mark.service は、SELinux を使用しない場合に限り無効にします。

sshd.service

yes

sshd.service は、OpenSSH サーバーへのリモートログインが必要ない場合に限り無効にします。

sssd.service

yes

sssd.service は、ネットワークを介して (たとえば LDAP や Kerberos を使用して) システムにログインするユーザーがいない場合に限り無効にします。sssd.service を無効にした場合は、すべての sssd-* ユニットを無効にすることを Red Hat は推奨します。

syslog.service

yes

rsyslog.service のエイリアス

tuned.service

yes

tuned.service は、パフォーマンスチューニングを使用する必要がない場合に限り無効にします。

lvm2-lvmpolld.socket

yes

lvm2-lvmpolld.socket は、論理ボリュームマネージャー (LVM) を使用しない場合に限り無効にします。

dnf-makecache.timer

yes

dnf-makecache.timerは、パッケージメターデータを自動的に更新する必要がない場合に限り無効にします。

unbound-anchor.timer

yes

unbound-anchor.timer は、DNSSEC (DNS Security Extensions) のルートトラストアンカーを毎日更新する必要がない場合に限り無効にします。このルートトラストアンカーは、DNSSEC 検証の Unbound リゾルバー、およびリゾルバーライブラリーにより使用されます。

サービスの詳細は、次のいずれかのコマンドを実行できます。

~]$ systemctl cat <service_name>
~]$ systemctl help <service_name>

systemctl cat コマンドは、/usr/lib/systemd/system/<service> 配下に置かれたサービスファイルの内容と、適用可能なすべてのオーバーライドを提供します。適用可能なオーバーライドには、/etc/systemd/system/<service> ファイルからのユニットファイルオーバーライドと、対応する unit.type.d ディレクトリーのドロップインファイルが含まれます。

ドロップインファイルの詳細は、man ページの systemd.unit を参照してください。

systemctl help コマンドは、特定サービスの man ページを表示します。