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

3.1. systemd の概要

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

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

表3.1 systemd のユニットファイルの場所

ディレクトリー説明

/usr/lib/systemd/system/

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

/run/systemd/system/

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

/etc/systemd/system/

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

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

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

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

表3.2 利用可能な systemd のユニットタイプ

ユニットのタイプファイルの拡張子説明

サービスユニット

.service

システムサービス

ターゲットユニット

.target

systemd ユニットのグループ

自動マウントユニット

.automount

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

デバイスユニット

.device

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

マウントユニット

.mount

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

パスユニット

.path

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

スコープユニット

.scope

外部作成のプロセス

スライスユニット

.slice

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

ソケットユニット

.socket

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

スワップユニット

.swap

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

タイマーユニット

.timer

systemd タイマー

system.conf を使用してデフォルトの systemd 設定の上書き

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

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

DefaultTimeoutStartSec=required value

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

3.1.1. 主な特長

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

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

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

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

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.11「タイムアウト制限の変更」を参照してください。

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

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) が表示されます。個別のサービスユニットの状態を判断する方法は「サービスステータスの表示」を参照してください。

例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 と、その名前

状態

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

Process

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

CGroup

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

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

systemctl is-active name.service

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

systemctl is-enabled name.service

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

例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) に置き換えます。このコマンドは、選択したサービスを現行セッションで開始します。システムの起動時にサービスユニットを開始するように設定する方法は「サービスの有効化」を参照してください。特定のサービスユニットのステータスを確認する方法は「サービスステータスの表示」を参照してください。

例3.5 サービスの起動

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

# systemctl start httpd.service

3.2.4. サービスの停止

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

systemctl stop name.service

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

例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

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

例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

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

例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 ターゲットでの作業

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

本セクションでは、systemd ターゲットでの作業中に実装する手順を説明します。

3.3.1. SysV ランレベルと systemd ターゲットの違い

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

Red Hat Enterprise Linux 7 では、以前のシステムリリースの標準ランレベルと類似する定義済みターゲットが多数同梱されています。互換性の理由から、このようなターゲットのエイリアスも SysV ランレベルに直接マッピングします。

以下の表では、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

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

以下の表は、SysV init コマンドを systemctl と比較しています。systemctl ユーティリティーを使用して、systemd ターゲットを表示、変更、または設定します。

重要

runlevel コマンドおよび telinit コマンドは今も利用でき、期待どおりに機能しますが、このコマンドは互換性のために同梱されているため、なるべく使用しないでください。

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

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

runlevel

systemctl list-units --type target

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

telinit runlevel

systemctl isolate name.target

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

関連情報

  • man sysv init
  • man upstart init
  • man systemctl

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

デフォルトのターゲットユニットは /etc/systemd/system/default.target ファイルで表されます。

手順

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

    $ systemctl get-default
    graphical.target
  • シンボリックリンクを使用してデフォルトのターゲットを確認するには、次のコマンドを実行します。

    $  ls -l /lib/systemd/system/default.target

3.3.3. ターゲットユニットの表示

デフォルトでは、systemctl list-units コマンドは、アクティブなユニットのみを表示します。

手順

  • 状態に関係なく読み込み済みユニットをすべて表示するには、以下のコマンドを実行します。

    $ systemctl list-units --type target --all
  • 現在読み込み済みのターゲットユニットの一覧を表示するには、以下のコマンドを実行します。

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

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

デフォルトのターゲットユニットは /etc/systemd/system/default.target ファイルで表されます。以下の手順では、systemctl コマンドを使用して、デフォルトのターゲットを変更する方法を説明します。

手順

  1. デフォルトのターゲットユニットを確認するには、次のコマンドを実行します。

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

    # 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

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

  3. 再起動します。

    # reboot

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

この手順では、systemctl コマンドを使用して、現行セッションでターゲットユニットを変更する方法を説明します。

手順

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

    # systemctl isolate multi-user.target

    このコマンドは、multi-user という名前のターゲットユニットと、その従属ユニットをすべて起動し、その他のユニットを直ちに停止します。

multi-user を、デフォルトで使用するターゲットユニット名に置き換えます。

検証手順

  • 新規作成された default.target を確認します。

    $ systemctl get-default
    multi-user.target

3.3.7. レスキューモードでの起動

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

手順

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

    # 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!

    このコマンドは systemctl isolate rescue.target と似ていますが、システムに現在ログインしているすべてのユーザーに情報メッセージを送信します。

    systemd がメッセージを送信しないようにするには、コマンドラインオプション --no-wall を付けて # systemctl --no-wall rescue を実行します。

3.3.8. 緊急モードでのブート

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

手順

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

    # systemctl emergency

このコマンドは systemctl isolate emergency.target と似ていますが、システムに現在ログインしているすべてのユーザーに情報メッセージを送信します。

systemd がメッセージを送信しないようにするには、--no-wall コマンドラインオプションを付けて # 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 ユニットファイルでの作業

本章では、systemd ユニットファイルに関する説明が含まれています。以下のセクションでは、次の方法を紹介します。

  • カスタムユニットファイルの作成
  • SysV Init スクリプトのユニットファイルへの変換
  • 既存のユニットファイルの変更
  • インスタンス化されたユニットの使用

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

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

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

unit_name.type_extension

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

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

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

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

3.5.2. ユニットファイル構造

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

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

3.5.2.1. [Unit] セクションの重要なオプション

以下の表は、[Unit] セクションの重要なオプションを示しています。

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

オプション[a]] セクションで設定可能なオプションの一覧は、systemd.unit(5) の man ページを参照してください。説明

説明

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

Documentation

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

After[b]

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

Requires

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

Wants

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

Conflicts

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

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

3.5.2.2. [Service] セクションの重要なオプション

以下の表では、[Service] セクションの重要なオプションを紹介しています。

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

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

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

3.5.2.3. [Install] セクションの重要なオプション

以下の表は、[Install] セクションの重要なオプションを紹介しています。

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

オプション[a]] セクションで設定可能なオプションの一覧は、systemd.unit (5) の man ページを参照してください。説明

Alias

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

RequiredBy

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

WantedBy

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

Also

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

DefaultInstance

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

[a] [Install

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

ユニットファイルをゼロから作成するユースケースが複数あります。カスタムデーモンを実行したり、一部の既存のサービスの 2 つ目のインスタンスを作成したり (「sshd サービスの 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 では、サービスを起動するターゲットを指定します。ターゲットは、従来のランレベルの概念に代わるものとお考えください。
  4. root で以下のコマンドを実行すると、新しい name.serviceファイルが存在することが、systemd に通知されます。

    systemctl daemon-reload
    
    systemctl start name.service
    警告

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

3.5.3.1. 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
  7. systemctl status コマンドを使用して sshd-second.service が実行中かどうかを確認します。
  8. さらに、サービスに接続して、ポートが正しく有効化されていることを確認します。

    ssh -p 22220 user@server

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

3.5.3.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.4. 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 スクリプトは例として使用されます。

3.5.4.1. systemd サービスの説明の検索

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

3.5.4.2. systemd サービス依存関係の検索

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

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

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

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

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

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

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

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

手順

  1. 必要とされる変更の程度に応じて、以下の方法のいずれかを実施してください。

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

    systemctl daemon-reload

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

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

    systemctl restart name.service
重要

SysV init スクリプトが処理しているサービスのプロパティ (依存関係やタイムアウトなど) を変更するときは、init スクリプト自体は変更しないでください。代わりに、「デフォルトのユニット設定の拡張」「デフォルトのユニット設定の上書き」にあるように、サービスの 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 と命名されるのはそのためです。

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

本セクションでは、追加の設定オプションでデフォルトのユニットファイルを拡張する方法を説明します。

手順

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

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

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

  2. 作成したディレクトリーに設定ファイルを作成します。ファイル名の接尾辞は .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 つのタスクだけを扱う簡単な設定ファイルを作成することが推奨されます。これにより、他のサービスの設定ディレクトリーに簡単に移動したり、リンクできます。

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

    systemctl daemon-reload
    systemctl restart name.service

例3.10 httpd.service 設定の拡張

Apache サービスの起動時にカスタムシェルスクリプトが自動的に実行されるように httpd.service ユニットを変更するには、以下の手順で行います。

  1. ディレクトリーおよびカスタム設定ファイルを作成します。

    # mkdir /etc/systemd/system/httpd.service.d/
    # touch /etc/systemd/system/httpd.service.d/custom_script.conf
  2. Apache で自動的に起動するスクリプトが /usr/local/bin/custom.sh にある場合は、以下のテキストを custom_script.conf ファイルに追加します。

    [Service]
    ExecStartPost=/usr/local/bin/custom.sh
  3. ユニットの変更を適用するには、以下を実行します。

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

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

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

本セクションでは、デフォルトのユニット設定を上書きする方法を説明します。

手順

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

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

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

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

    systemctl daemon-reload
    systemctl restart name.service

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

サービスごとにタイムアウト値を指定すると、正常に動作していないサービスによってシステムがフリーズすることを防ぐことができます。タイムアウト値を指定しないサービスには、通常のサービスの場合は 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 を変更します。

3.5.5.3. 上書きされたユニットの監視

本セクションでは、上書きされたユニットファイルまたは変更されたユニットファイルの概要を表示する方法を説明します。

手順

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

    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.5.6. インスタンス化されたユニットの使用

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

たとえば、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.5.6.1. 重要なユニット指定子

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

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

ユニット指定子意味説明

%n

完全ユニット名

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

%p

接頭辞名

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

%i

インスタンス名

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

%H

ホスト名

ユニット設定を読み込んだ時に稼働しているシステムのホスト名を表します。

%t

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

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

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

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

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

本セクションでは、以下を説明します。

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

3.6.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 で重要なものを分析

3.6.2. 無効にしても安全なサービスを選択するためのガイド

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

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

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

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

# systemctl disable service_name

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

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

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

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

サービス名無効にすることは可能か?詳細情報

auditd.service

はい

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

autovt@.service

いいえ

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

crond.service

はい

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

dbus-org.fedoraproject.FirewallD1.service

はい

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

dbus-org.freedesktop.NetworkManager.service

はい

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

dbus-org.freedesktop.nm-dispatcher.service

はい

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

firewalld.service

はい

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

getty@.service

いいえ

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

import-state.service

はい

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

irqbalance.service

はい

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

kdump.service

はい

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

loadmodules.service

はい

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

lvm2-monitor.service

はい

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

microcode.service

いいえ

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

NetworkManager-dispatcher.service

はい

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

NetworkManager-wait-online.service

はい

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

NetworkManager.service

はい

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

nis-domainname.service

はい

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

rhsmcertd.service

いいえ

 

rngd.service

はい

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

rsyslog.service

はい

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

selinux-autorelabel-mark.service

はい

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

sshd.service

はい

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

sssd.service

はい

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

syslog.service

はい

rsyslog.service のエイリアス

tuned.service

はい

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

lvm2-lvmpolld.socket

はい

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

dnf-makecache.timer

はい

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

unbound-anchor.timer

はい

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 ページを表示します。

3.7. 関連情報

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

3.7.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.7.2. オンラインドキュメント

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

このページには機械翻訳が使用されている場合があります (詳細はこちら)。