Show Table of Contents
10.6. システムのユニットファイルの作成および変更
ユニットファイルには、ユニットを説明し、その動作を定義する設定ディレクティブが含まれます。複数の
systemctl コマンドがバックグラウンドでユニットファイルと動作します。細かい調整を行うには、システム管理者は手動でユニットファイルを編集するか、または作成する必要があります。表10.2「Systemd Unit ファイルの場所」 は、システム上のユニットファイルが保存される 3 つのメインディレクトリーを一覧表示し、/etc/systemd/system/ ディレクトリーは、システム管理者が作成するか、またはカスタマイズするユニットファイル用に予約されます。
ユニットファイル名は以下のフォーマットを使用します。
unit_name.type_extension
ここで、unit_name はユニットの名前を表し、type_extension はユニットタイプを特定します。ユニットタイプの詳細な一覧については、表10.1「利用可能な systemd Unit タイプ」 を参照してください。たとえば、通常システムには
sshd.service および sshd.socket ユニットがあります。
ユニットファイルには、追加の設定ファイルのディレクトリーを追加できます。たとえば、カスタム設定オプションを
sshd.service に追加するには、sshd.service.d/custom.conf ファイルを追加し、追加のディレクティブを挿入します。設定ディレクティブについての詳細情報は、「既存のユニットファイルの変更」 を参照してください。
さらに、
sshd.service.wants/ および sshd.service.requires/ ディレクトリーを作成することもできます。それらのディレクトリーには、sshd サービスの依存関係であるユニットファイルへのシンボリックリンクが含まれます。シンボリックリンクは、[Install] ユニットファイルオプションに従ってインストール時に自動的に作成されるか (表10.11「[Install] セクションの重要なオプション」 を参照)、または [Unit] オプションに基づいてランタイム時に自動的に作成されます (表10.9「[Unit] セクションの重要なオプション」 を参照)。さらに、それらのディレクトリーおよびシンボリックリンクを手動で作成することもできます。
多くのユニットファイルオプションは、いわゆる ユニット指定子 を使用して設定できます。これは、ユニットファイルが読み込まれる際にユニットパラメーターに動的に置き換えられるワイルドカード文字列です。これにより、インスタンス化されるユニットを生成するためのテンプレートとして機能する汎用ユニットファイルを作成できます。詳細は、「インスタンス化されたユニットの使用」 を参照してください。
10.6.1. ユニットファイル構造の概要
通常、ユニットファイルは 3 つのセクションで構成されています。
- [Unit] — ユニットのタイプに依存しない汎用的なオプションが含まれます。これらのオプションはユニットの説明を提供し、ユニットの動作を指定し、他のユニットへの依存関係を設定します。最もよく使われる [Unit] オプションの一覧については、表10.9「[Unit] セクションの重要なオプション」 を参照してください。
- [unit type] — ユニットにタイプ固有のディレクティブがある場合、それらはユニットタイプに基づいて名前が付けられるセクションにグループ分けされます。たとえば、サービスユニットファイルには [Service] セクションが含まれます。最もよく使われる [Service] オプションについては、表10.10「[Service] セクションの重要なオプション」 を参照してください。
- [Install] —
systemctl enableおよびdisableコマンドで使用されるインストールについての情報が含まれます。[Install] オプションの一覧については、表10.11「[Install] セクションの重要なオプション」 を参照してください。
表10.9 [Unit] セクションの重要なオプション
| オプション[a] | 詳細 |
|---|---|
Description | ユニットの分かりやすい説明です。このテキストは、たとえば systemctl status コマンドの出力に表示されます。 |
Documentation | ユニットのドキュメントを参照する URI の一覧を提供します。 |
After[b] | ユニットが開始される順序を定義します。ユニットは、After で指定されたユニットがアクティブにされた後にのみ開始されます。Requires とは異なり、After は指定されたユニットを明示的にアクティブ化しません。Before オプションには、After とは反対の機能があります。 |
Requires | 他のユニットに依存関係を設定します。Requires に一覧表示されるユニットは、該当ユニットと共にアクティブ化されます。必要なユニットのいずれかが開始しない場合、ユニットはアクティブ化されません。 |
Wants | Requires よりも強度の弱い依存関係を設定します。一覧表示されるユニットのいずれかが正常に開始しない場合も、ユニットのアクティべーションには影響を与えません。これは、カスタムのユニット依存関係を設定する際に推奨される方法です。 |
Conflicts | Requires とは反対の、負の依存関係を設定します。 |
[a]
[Unit] セクションで設定可能なオプションの詳細な一覧は、 systemd.unit(5) man ページを参照してください。
[b]
ほとんどの場合、 After および Before ユニットファイルオプションで依存関係の並び順を設定するだけで十分です。Wants (推奨) または Requires で要件の依存関係も設定する場合、依存関係の並び順は指定する必要があります。これは、並び順と要件の依存関係が相互に依存していないためです。
| |
表10.10 [Service] セクションの重要なオプション
| オプション[a] | 詳細 |
|---|---|
Type | ExecStart および関連オプションの機能に影響を与えるユニットプロセスの起動タイプを設定します。以下のいずれかになります。
|
ExecStart | ユニットの起動時に実行されるコマンドまたはスクリプトを指定します。ExecStartPre および ExecStartPost は、ExecStart の前後に実行されるカスタムコマンドを指定します。Type=oneshot は、順次に実行される複数のカスタムコマンドの指定を可能にします。 |
ExecStop | ユニットの停止時に実行されるコマンドまたはスクリプトを指定します。 |
ExecReload | ユニットの再読み込み時に実行されるコマンドまたはスクリプトを指定します。 |
Restart | このオプションが有効にされた状態で、サービスは systemctl コマンドによる完全な停止の例外と共に、そのプロセスの終了後に再起動します。 |
RemainAfterExit | True に設定される場合、サービスは、そのプロセスがすべて終了していてもアクティブと見なされます。デフォルトの値は False です。このオプションは、Type=oneshot が設定されている場合にとくに役に立ちます。 |
[a]
[Service] セクションで設定可能なオプションの詳細な一覧は、 systemd.service(5) man ページを参照してください。
| |
表10.11 [Install] セクションの重要なオプション
| オプション[a] | 詳細 |
|---|---|
Alias | ユニットの追加の名前のスペース区切りの一覧を提供します。systemctl enable を除くほとんどの systemctl コマンドは、実際のユニット名の代わりにエイリアスを使うことができます。 |
RequiredBy | 該当ユニットに依存するユニットの一覧です。このユニットが有効な場合、RequiredBy に一覧表示されるユニットは、このユニットについての Require 依存関係を取得します。 |
WantedBy | 該当ユニットに弱く依存するユニットの一覧です。このユニットが有効な場合、WantedBy に一覧表示されるユニットは、このユニットについての Want 依存関係を取得します。 |
Also | 該当ユニットと共にインストールまたはアンインストールされるユニットの一覧を指定します。 |
DefaultInstance | インスタンス化されたユニットに制限された状態で、このオプションは、ユニットが有効にされているデフォルトインスタンスを指定します。「インスタンス化されたユニットの使用」 を参照してください。 |
[a]
[Install] セクションで設定可能なオプションの詳細な一覧は、 systemd.unit(5) man ページを参照してください。
| |
ユニット設定を微調整するために使用できる様々なオプションがあります。例10.17「postfix.service ユニットファイル」 は、システムにインストールされたサービスユニットの例を示しています。さらに、ユニットファイルのオプションは、「インスタンス化されたユニットの使用」 に説明されているようにユニットの動的な作成が可能な方法で定義できます。
例10.17 postfix.service ユニットファイル
次に、postfix パッケージで現在提供されている
/usr/lib/systemd/system/postifix.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] セクションはサービスに依存するユニットを一覧表示します。
10.6.2. カスタムユニットファイルの作成
ユニットファイルをゼロから作成するための複数のユースケースがあります。カスタムデーモンを実行したり、(例10.19「sshd サービスの 2 つ目のインスタンスの作成」 に説明されているように) 一部の既存サービスの 2 つ目のインスタンスを作成したり、または SysV init スクリプトをインポート (詳細は 「SysV Init スクリプトのユニットファイルへの変換」 を参照) したりできます。一方、既存ユニットの動作の変更または拡張のみを実行しようとする場合は、「既存のユニットファイルの変更」 の指示に従ってください。以下の手順では、カスタムサービスを作成する一般的なプロセスについて説明しています。
- カスタムサービスで実行可能ファイルを用意します。これは、カスタムで作成されたスクリプトである場合も、ソフトウェアプロバイダーが提供する実行可能ファイルである場合もあります。必要な場合は、カスタムサービスのメインプロセスの一定の PID を保持するために PID ファイルを用意します。また、サービスのシェル変数を保存するために環境ファイルを組み込むこともできます。ソーススクリプトが (
chmod a+xを実行して) 実行可能であり、インタラクティブではないことを確認します。 /etc/systemd/system/ディレクトリーにユニットファイルを作成し、これに正しいファイルパーミッションが含まれることを確認します。rootで実行します。touch/etc/systemd/system/name.servicechmod 664/etc/systemd/system/name.servicename を、作成されるサービスの名前に置き換えます。ファイルは実行可能でなくてもよいことに注意してください。- 直前のステップで作成された
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 で作成されます。表10.10「[Service] セクションの重要なオプション」 で他の起動タイプを検索します。WantedByは、サービスを起動する必要のあるターゲットを提示します。これらのターゲットは、ランレベルの古い概念の置き換えと見なすことができます。詳細は、「systemd ターゲットでの作業」 を参照してください。
rootで以下のコマンドを実行して、systemd に対して、新規のname.serviceファイルが存在することを通知します。systemctldaemon-reloadsystemctl start name.service警告
新規のユニットファイルの作成または既存のユニットファイルの変更後に常にsystemctl daemon-reloadコマンドを実行します。実行しないと、systemctl startまたはsystemctl enableコマンドは、systemd とディスク上の実際のサービスユニットファイルの状態の間にある不一致により失敗する可能性があります。name.service ユニットは、「システムサービスの管理」 に説明されているコマンドでその他のシステムサービスとして管理することができます。
例10.18 emacs.service ファイルの作成
Emacs テキストエディターを使用する場合、ファイルの編集時にプログラムの新規インスタンスを起動するのではなく、これをバックグラウンドで実行する方がスピードが早く、便利です。以下のステップでは、Emacs のユニットファイルを作成する方法を説明し、これをサービスのように処理できるようにします。
/etc/systemd/system/ディレクトリーにユニットファイルを作成し、これに正しいファイルパーミッションが含まれることを確認します。rootで実行します。~]#
touch~]#/etc/systemd/system/emacs.servicechmod 664/etc/systemd/system/emacs.service- 以下の内容をファイルに追加します。
[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 プロセスを再起動します。 - 設定を再読み込みし、カスタムサービスを起動するために以下のコマンドを実行します。
~]#
systemctl~]#daemon-reloadsystemctl start emacs.service
これでエディターは systemd サービスとして登録されるので、すべての標準的な
systemctl コマンドが使用できます。例えば、systemctl status emacs でエディターのステータスを表示したり、systemctl enable emacs でシステム起動時にエディターを自動的に起動することができます。
例10.19 sshd サービスの 2 つ目のインスタンスの作成
システム管理者は、サービスの複数のインスタンスを設定し、実行しなければならないことが多くあります。これは、元のサービス設定ファイルのコピーを作成し、サービスの主なインスタンスとの競合を避けるために特定のパラメーターを変更することによって実行されます。以下の手順は、
sshd サービスの 2 つ目のインスタンスを作成する方法を示しています。
- 2 つ目のデーモンで使用される
sshd_configファイルのコピーを作成します。~]#
cp /etc/ssh/sshd{,-second}_config - 直前のステップで作成された
sshd-second_configファイルを編集し、異なるポート番号と PID ファイルを 2 つ目のデーモンに割り当てます。Port 22220 PidFile /var/run/sshd-second.pid
PortおよびPidFileオプションの詳細は、sshd_config(5) man ページを参照してください。選択するポートがその他のサービスで使用されていないことを確認します。PID ファイルはサービスの実行前になければならない訳ではありません。これはサービスの起動時に自動的に生成されます。 sshdサービスの systemd ユニットファイルのコピーを作成します。~]#
cp /usr/lib/systemd/system/sshd.service /etc/systemd/system/sshd-second.service- 直前のステップで作成された
sshd-second.serviceを変更します。Descriptionオプションを変更します。Description=OpenSSH server second instance daemon
Afterオプションで指定されたサービスに sshd.service を追加し、2 つ目のインスタンスが、最初のインスタンスが起動した後にのみ起動するようにします。After=syslog.target network.target auditd.service sshd.service
- sshd の最初のインスタンスには鍵の生成が含まれるため、ExecStartPre=/usr/sbin/sshd-keygen 行を削除します。
-f /etc/ssh/sshd-second_configパラメーターをsshdコマンドに追加し、代替の設定ファイルが使用されるようにします。ExecStart=/usr/sbin/sshd -D -f /etc/ssh/sshd-second_config $OPTIONS
- 上記の変更後、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
- SELinux を使用している場合、sshd の 2 番目のインスタンスのポートを SSH ポートに追加します。そうしないと、sshd の 2 番目のインスタンスはポートへのバインドの際に拒否されます。
~]#
semanage port -a -t ssh_port_t -p tcp 22220 - sshd-second.service を有効にし、これがブート時に自動的に起動するようにします。
~]#
systemctl enable sshd-second.servicesystemctl statusコマンドを使用して sshd-second.service が実行中であるかどうかを確認します。さらに、ポートがサービスに接続することによって適切に有効にされているかどうかを確認します。~]$
ssh -p 22220 user@serverファイアウォールを使用中の場合、sshd の 2 番目のインスタンスへの接続を許可するためにそれが適切に設定されていることを確認してください。
カスタムユニットファイルの並び順および依存関係のターゲットを適切に選択する方法については、以下の記事を参照してください。
ユニットファイルの並び順および依存関係にトリガーされたケースの実例の一部と追加情報については、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 ログインセッションを使用しません。
10.6.3. SysV Init スクリプトのユニットファイルへの変換
SysV init スクリプトをユニットファイルに変換する前に、どこか他の場所で変換がすでに行われていないことを確認します。Red Hat Enterprise Linux 7 にインストールされるすべてのコアサービスにデフォルトのユニットファイルが同梱されていますが、数多くのサードパーティーソフトウェアパッケージにも同様のことことが言えます。
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 スクリプトはサンプルとして使用されます。例10.17「postfix.service ユニットファイル」 で作成される postfix ユニットについて参照してください。
サービス説明の検索
#description で始まる行でスクリプトについての説明情報をを見つけてください。この説明をサービス名と共に、ユニットファイルの [Unit] セクションの
Description オプションで使用します。LSB ヘッダーでは、#Short-Description および #Description 行に同様のデータが含まれる場合があります。
サービス依存関係の検索
LSB ヘッダーには、サービス間の依存関係を形成する複数のディレクティブが含まれる場合があります。それらのほとんどは systemd ユニットオプションに変換できます。表10.12「LSB ヘッダーの依存関係オプション」 を参照してください。
表10.12 LSB ヘッダーの依存関係オプション
| LSB オプション | 詳細 | 同等のユニットファイル |
|---|---|---|
Provides | サービスの起動ファシリティー名を指定します。この名前は他の init スクリプトで参照できます ( "$" 接頭辞を使用)。ただしこれは、ユニットファイルが他のユニットをファイル名で参照できるようになったため、不要になりました。 | – |
Required-Start | 必要なサービスの起動ファシリティー名が含まれます。これは、並び順依存関係として変換され、起動ファシリティー名は対応するサービスまたはそれらが属するターゲットに置き換えられます。たとえば、postfix の場合、$network の Required-Start 依存関係は network.target で After 依存関係に変換されました。 | After、Before |
Should-Start | Required-Start よりも弱い依存関係を構成します。失敗した Should-Start 依存関係はサービス起動に影響を与えません。 | After、Before |
Required-Stop、Should-Stop | 負の依存関係を構成します。 | Conflicts |
サービスのデフォルトターゲットの検索
#chkconfig で始まる行には、3 つの数値が含まれます。最も重要な値は、サービスが起動するデフォルトのランレベルを表す最初の番号です。これらのランレベルを同等の systemd ターゲットにマップするには、表10.6「SysV ランレベルと systemd ターゲットの比較」 を使用します。次に、それらのターゲットをユニットファイルの [Install] セクションの
WantedBy オプションに一覧表示します。たとえば、postfix はこれまではランレベル 2、3、4、および 5 で起動しました。これらは Red Hat Enterprise Linux 7 の multi-user.target および graphical.target に変換されます。graphical.target は multiuser.target に依存するため、例10.17「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 は事前に定義されたアクションのみをサポートしますが、
ExecStart、ExecStartPre、ExecStartPost、ExecStop、および ExecReload オプションでカスタム実行可能ファイルを実行することができます。Red Hat Enterprise Linux 7 の postfix の場合、/usr/sbin/postfix はサポートスクリプトと共に、サービスの起動時に実行されます。postfix ユニットファイルについては、例10.17「postfix.service ユニットファイル」 を参照してください。
複雑な init スクリプトを変換する際には、スクリプトのすべてのステートメントの目的を理解している必要があります。一部のステートメントはオペレーティングシステムのバージョンに固有のものであるため、それらを変更する必要はありません。一方、新規の環境では、サービス実行可能ファイルおよびサポートファイルやユニットファイルで調整が一部必要となる場合があります。
10.6.4. 既存のユニットファイルの変更
システムにインストールされるサービスは、
/usr/lib/systemd/system/ ディレクトリーに保存されるデフォルトのユニットファイルと共に提供されます。システム管理者はこれらのファイルを直接変更できないため、カスタマイズは /etc/systemd/system/ ディレクトリーの設定ファイルに制限される必要があります。必要とされる変更の程度に応じて、以下の方法のいずれかを実施してください。
- 補助設定ファイルのディレクトリーを
/etc/systemd/system/unit.d/に作成します。この方法は、ほとんどのユースケースで推奨されます。これにより、元のユニットファイルを参照しつつも、デフォルト設定を追加の機能で拡張できます。この場合、パッケージの更新で導入されるデフォルトユニットへの変更は自動的に適用されます。詳細は、「デフォルトのユニット設定の拡張」 を参照してください。 - 元のユニットファイル
/usr/lib/systemd/system/のコピーを/etc/systemd/system/に作成し、そこで変更を行います。コピーは元のファイルを上書きするため、パッケージの更新で導入される変更は適用されません。この方法は、パッケージの更新とは無関係に永続する重要なユニット変更を行う際に役に立ちます。詳細は、「デフォルトのユニット設定の上書き」 を参照してください。
ユニットのデフォルト設定に戻るには、
/etc/systemd/system/ でカスタム作成した設定ファイルを削除します。システムを再起動せずにユニットファイルへの変更を適用するには、以下を実行します。
systemctl daemon-reloaddaemon-reload オプションは、すべてのユニットファイルを再読み込みし、ユニットファイルに変更をすぐに適用するために必要な依存関係ツリー全体を再作成します。または、以下のコマンドを使って同じ結果を得ることができます。
init q
変更されたユニットファイルが実行中のサービスに属する場合は、このサービスは、新たな設定を受け入れるために再起動する必要があります。
systemctl restart name.service重要
SysV init スクリプトが処理しているサービスのプロパティ (依存関係やタイムアウトなど) を変更するときは、init スクリプト自体は変更しないでください。代わりに、 「デフォルトのユニット設定の拡張」 と 「デフォルトのユニット設定の上書き」 にあるように、サービスの
systemd ドロップイン設定ファイルを作成します。その後、通常の systemd サービスと同じ方法でサービスを管理します。
たとえば、
network サービスの設定を拡張するときは、/etc/rc.d/init.d/network init スクリプトファイルは変更せず、代わりに新しいディレクトリ /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 で以下を実行します。
systemctldaemon-reloadsystemctl restart name.service
例10.20 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-reloadsystemctl restart httpd.service
注記
/etc/systemd/system/ の設定ディレクトリーの設定ファイルは、/usr/lib/systemd/system/ のファイルに優先されます。そのため、設定ファイルに Description または ExecStart などの 1 回のみ指定できるオプションが含まれる場合、このオプションのデフォルト値が上書きされます。「上書きされたユニットのモニタリング」 で説明されているように、systemd-delta コマンドの出力では、一部のオプションは実際に上書きされますが、該当のユニットは常に [EXTENDED] とマークされます。
デフォルトのユニット設定の上書き
ユニットファイルを提供するパッケージの更新後も永続する変更を加えるには、まずファイルを
/etc/systemd/system/ ディレクトリーにコピーします。これを実行するには、root で以下のコマンドを実行します。
cp /usr/lib/systemd/system/name.service /etc/systemd/system/name.service
ここで、name は、変更する必要のあるサービスユニットの名前を表します。上記の構文はすべてのユニットタイプに劇用されます。
テキストエディターでコピーされたファイルを開き、必要な変更を行います。ユニットの変更を適用するには、
root で以下を実行します。
systemctldaemon-reloadsystemctl restart name.service
例10.21 タイムアウト制限の変更
サービスごとにタイムアウト値を指定すると、正常に動作していないサービスによってシステムがフリーズすることを防止できます。指定しない場合、タイムアウトは通常のサービスには 90 秒、SysV と互換性のあるサービスには 300 秒に、それぞれデフォルト設定されています。
たとえば、
httpd サービスのタイムアウト制限を延長するときは。
httpdユニットファイルを/etc/systemd/system/ディレクトリへコピーします。cp /usr/lib/systemd/system/httpd.service /etc/systemd/system/httpd.service- ファイル
/etc/systemd/system/httpd.serviceを開き、TimeoutStartUSec値を[Service]セクションで指定します。... [Service]... PrivateTmp=true TimeoutStartSec=10 [Install] WantedBy=multi-user.target...
systemdデーモンを再読み込みします。systemctl daemon-reload- オプション。 新しいタイムアウト値を検証します。
systemctl show httpd -p TimeoutStartUSec
注記
タイムアウト値をグローバルに変更するには、
DefaultTimeoutStartSec を /etc/systemd/system.conf ファイルに入力します。「systemd の概要」 を参照してください。
上書きされたユニットのモニタリング
上書きされたか、または変更されたユニットファイルの概要を表示するには、以下のコマンドを使用します。
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.
表10.13「systemd-delta の相違タイプ」 は、
systemd-delta の出力で表示される上書きタイプを一覧表示します。ファイルが上書きされる場合、systemd-delta はデフォルトで、diff コマンドの出力に似た変更の要約を表示します。
表10.13 systemd-delta の相違タイプ
| タイプ | 詳細 |
|---|---|
|
[MASKED]
|
マスクされたユニットファイルです。ユニットのマスクについての説明は、「サービスの無効化」 を参照してください。
|
|
[EQUIVALENT]
|
元のファイルを上書きするが、コンテンツに相違のない変更されていないコピーです。通常はシンボリックリンクです。
|
|
[REDIRECTED]
|
別のファイルにリダイレクトされるファイルです。
|
|
[OVERRIDEN]
|
上書きされ、変更されたファイルです。
|
|
[EXTENDED]
| /etc/systemd/system/unit.d/ ディレクトリーの .conf ファイルで拡張されるファイルです。
|
|
[UNCHANGED]
| --type=unchanged オプションが使用される場合にのみ表示される変更されないファイルです。
|
システムの更新後に、カスタム設定で上書きされているデフォルトユニットへの更新があるかどうかを確認するために
systemd-delta を実行することができます。さらに、出力を特定の相違タイプに制限することもできます。たとえば、上書きされたユニットのみを表示するには、以下を実行します。
systemd-delta --type=overridden10.6.5. インスタンス化されたユニットの使用
ランタイム時に単一の設定ファイルから複数のユニットをインスタンス化することができます。"@" 文字は、テンプレートにマークを付け、ユニットをこれに関連付けるために使用されます。インスタンス化されたユニットは、(
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 に指定されたサービスユニット検索させます。該当するユニットが見つからない場合、「@」とタイプ接尾辞の間の部分は無視され、systemd は
getty@.service ファイルを検索し、そこから設定を読み取り、サービスを起動します。
ワイルドカード文字 (ユニット指定子 とも呼ばれる) をすべてのユニット設定ファイルで使用できます。ユニット指定子は特定のユニットパラメーターを置き換え、これらはランタイム時に解釈されます。表10.14「重要なユニット指定子」 は、テンプレートユニットでとくに役立つユニット指定子を一覧表示します。
表10.14 重要なユニット指定子
| ユニット指定子 | 意味 | 詳細 |
|---|---|---|
%n | 完全ユニット名 | タイプ接尾辞を含む完全ユニット名を表します。%N には同じ意味がありますが、禁止文字を ASCII コードに置き換えます。 |
%p | 接頭辞名 | タイプ接尾辞が削除されたユニット名を表します。インスタンス化されたユニットの %p は、ユニット名の「@」文字の前の部分を表します。 |
%i | インスタンス名 | インスタンス化されたユニット名の「@」文字およびタイプ接尾辞間の部分です。%I には同じ意味がありますが、禁止文字を ASCII コードにも置き換えます。 |
%H | ホスト名 | ユニット設定が読み込まれる時点の実行中システムのホスト名を表します。 |
%t | ランタイムディレクトリー | ランタイムディレクトリーを表します。これは root ユーザーの /run か、または特権のないユーザーの XDG_RUNTIME_DIR 変数の値のいずれかになります。 |
ユニット指定子の詳細な一覧については、
systemd.unit(5) man ページを参照してください。
たとえば、
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 として解決されます。
Where did the comment section go?
Red Hat's documentation publication system recently went through an upgrade to enable speedier, more mobile-friendly content. We decided to re-evaluate our commenting platform to ensure that it meets your expectations and serves as an optimal feedback mechanism. During this redesign, we invite your input on providing feedback on Red Hat documentation via the discussion platform.