Systemdユニットとユニットファイルについて

前書き

Linuxディストリビューションでは、systemdinitシステムを採用または採用する予定がますます増えています。この強力なソフトウェアスイートは、サービスからマウントされたデバイスやシステム状態に至るまで、サーバーの多くの側面を管理できます。

systemdでは、unitは、システムが操作および管理する方法を知っているすべてのリソースを指します。これは、systemdツールが処理方法を知っている主要なオブジェクトです。これらのリソースは、ユニットファイルと呼ばれる構成ファイルを使用して定義されます。

このガイドでは、systemdが処理できるさまざまな単位を紹介します。また、これらのリソースがシステムで処理される方法を形成するために、ユニットファイルで使用できる多くのディレクティブの一部を取り上げます。

Systemdユニットは何を提供しますか？

ユニットは、systemdが管理方法を知っているオブジェクトです。これらは基本的に、デーモンのスイートによって管理され、提供されたユーティリティによって操作されるシステムリソースの標準化された表現です。

ある意味でのユニットは、他の初期化システムのサービスやジョブに似ていると言えます。ただし、ユニットは、サービス、ネットワークリソース、デバイス、ファイルシステムマウント、および分離されたリソースプールを抽象化するために使用できるため、はるかに広い定義を持っています。

他のinitシステムでは、1つの統一されたサービス定義で処理できるという考えは、焦点に応じてコンポーネントユニットに分割できます。これは機能別に整理され、ユニットのコア動作を変更せずに機能を簡単に有効化、無効化、または拡張できます。

ユニットが簡単に実装できる機能は次のとおりです。

socket-based activation：サービスに関連付けられたソケットは、個別に処理するためにデーモン自体から切り離すのが最適です。これには、関連するソケットが最初にアクセスされるまでサービスの開始を遅らせるなど、多くの利点があります。これにより、システムはブートプロセスの早い段階ですべてのソケットを作成できるため、関連するサービスを並行してブートできます。
bus-based activation：ユニットは、D-Busによって提供されるバスインターフェイスでもアクティブ化できます。ユニットは、関連するバスが公開されたときに開始できます。
path-based activation：ユニットは、特定のファイルシステムパスでのアクティビティまたは可用性に基づいて起動できます。これはinotifyを利用します。
device-based activation：ユニットは、udevイベントを利用して、関連するハードウェアが最初に利用可能になったときに起動することもできます。
implicit dependency mapping：ユニットの依存関係ツリーのほとんどは、systemd自体で構築できます。依存関係と注文情報を追加することもできますが、ほとんどの面倒な作業は面倒を見てくれます。
instances and templates：テンプレートユニットファイルを使用して、同じ一般ユニットの複数のインスタンスを作成できます。これにより、すべてが同じ一般的な機能を提供するわずかなバリエーションまたは兄弟ユニットが可能になります。
easy security hardening：ユニットは、単純なディレクティブを追加することで、かなり優れたセキュリティ機能を実装できます。たとえば、ファイルシステムの一部へのアクセスなしまたは読み取り専用アクセスを指定したり、カーネル機能を制限したり、プライベート/tmpとネットワークアクセスを割り当てたりすることができます。
drop-ins and snippets：システムのユニットファイルの一部を上書きするスニペットを提供することで、ユニットを簡単に拡張できます。これにより、バニラとカスタマイズされたユニットの実装を簡単に切り替えることができます。

systemdユニットには、他のinitシステムの作業項目に比べて他にも多くの利点がありますが、これにより、ネイティブ構成ディレクティブを使用して活用できる能力を理解できます。

Systemd Unitファイルはどこにありますか？

systemdがユニットを処理する方法を定義するファイルは、さまざまな場所にあり、それぞれに異なる優先順位と影響があります。

システムのユニットファイルのコピーは、通常、/lib/systemd/systemディレクトリに保存されます。ソフトウェアがユニットファイルをシステムにインストールするとき、これはデフォルトで配置される場所です。

ここに保存されているユニットファイルは、セッション中にオンデマンドで開始および停止できます。これは一般的なバニラユニットファイルであり、多くの場合、アップストリームプロジェクトのメンテナによって作成され、標準実装でsystemdをデプロイするすべてのシステムで動作する必要があります。このディレクトリ内のファイルを編集しないでください。代わりに、必要に応じて、この場所のファイルを置き換える別のユニットファイルの場所を使用して、ファイルをオーバーライドする必要があります。

ユニットの機能を変更したい場合は、/etc/systemd/systemディレクトリ内が最適な場所です。このディレクトリの場所にあるユニットファイルは、ファイルシステム上の他の場所よりも優先されます。システムのユニットファイルのコピーを変更する必要がある場合は、このディレクトリに置換を置くのが最も安全で柔軟な方法です。

システムのユニットファイルから特定のディレクティブのみをオーバーライドする場合は、サブディレクトリ内でユニットファイルスニペットを実際に提供できます。これらにより、システムのコピーのディレクティブが追加または変更され、変更するオプションのみを指定できます。

これを行う正しい方法は、ユニットファイルにちなんで名付けられたディレクトリを作成し、末尾に.dを追加することです。したがって、example.serviceというユニットの場合、example.service.dというサブディレクトリを作成できます。このディレクトリ内で、.confで終わるファイルを使用して、システムのユニットファイルの属性を上書きまたは拡張できます。

実行時の単位定義の場所も/run/systemd/systemにあります。このディレクトリにあるユニットファイルは、/etc/systemd/systemと/lib/systemd/systemの間に優先的に着陸します。この場所にあるファイルは、前者の場所よりも重みが小さくなりますが、後者よりも重みが大きくなります。

systemdプロセス自体は、実行時に作成される動的に作成されたユニットファイルにこの場所を使用します。このディレクトリを使用して、セッション中にシステムのユニットの動作を変更できます。サーバーを再起動すると、このディレクトリで行われたすべての変更は失われます。

ユニットの種類

Systemdは、説明するリソースのタイプに応じて単位を分類します。ユニットのタイプを判別する最も簡単な方法は、リソース名の最後に追加されるタイプサフィックスを使用することです。次のリストは、systemdで使用可能なユニットのタイプを示しています。

.service：サービスユニットは、サーバー上のサービスまたはアプリケーションを管理する方法を記述します。これには、サービスを開始または停止する方法、その状況で自動的に開始する必要がある方法、および関連ソフトウェアの依存関係と注文情報が含まれます。
.socket：ソケットユニットファイルは、ネットワークまたはIPCソケット、またはsystemdがソケットベースのアクティベーションに使用するFIFOバッファーを記述します。これらには常に関連する.serviceファイルがあり、このユニットが定義するソケットでアクティビティが検出されたときに開始されます。
.device：udevまたはsysfsファイルシステムによってsystemd管理が必要であると指定されたデバイスを記述するユニット。すべてのデバイスに.deviceファイルがあるわけではありません。 .deviceユニットが必要になる可能性があるいくつかのシナリオは、デバイスの注文、取り付け、およびアクセスのためです。
.mount：このユニットは、systemdによって管理されるシステム上のマウントポイントを定義します。これらは、マウントパスに基づいて名前が付けられ、スラッシュがダッシュに変更されます。 /etc/fstab内のエントリには、ユニットを自動的に作成できます。
.automount：.automountユニットは、自動的にマウントされるマウントポイントを構成します。これらは、参照するマウントポイントにちなんで名前を付ける必要があり、マウントの詳細を定義するには、一致する.mount単位が必要です。
.swap：この単位は、システムのスワップスペースを表します。これらのユニットの名前は、スペースのデバイスまたはファイルパスを反映している必要があります。
.target：ターゲットユニットは、起動時または状態の変更時に他のユニットに同期ポイントを提供するために使用されます。また、システムを新しい状態にするためにも使用できます。他のユニットは、ターゲットとの関係を指定して、ターゲットの操作に結び付けます。
.path：このユニットは、パスベースのアクティベーションに使用できるパスを定義します。デフォルトでは、パスが指定された状態に達すると、同じベース名の.serviceユニットが開始されます。これは、inotifyを使用してパスの変更を監視します。
.timer：.timerユニットは、遅延またはスケジュールされたアクティブ化のcronジョブと同様に、systemdによって管理されるタイマーを定義します。タイマーに達すると、一致するユニットが開始されます。
.snapshot：.snapshotユニットは、systemctl snapshotコマンドによって自動的に作成されます。変更後、システムの現在の状態を再構築できます。スナップショットはセッション間で存続せず、一時的な状態をロールバックするために使用されます。
.slice：.sliceユニットはLinuxコントロールグループノードに関連付けられており、リソースを制限したり、スライスに関連付けられたプロセスに割り当てたりすることができます。この名前は、cgroupツリー内の階層位置を反映しています。ユニットは、そのタイプに応じてデフォルトで特定のスライスに配置されます。
.scope：スコープユニットは、バスインターフェイスから受信した情報からsystemdによって自動的に作成されます。これらは、外部で作成されたシステムプロセスのセットを管理するために使用されます。

ご覧のとおり、systemdが管理方法を知っているさまざまなユニットがあります。多くのユニットタイプが連携して機能を追加します。たとえば、一部のユニットは、他のユニットをトリガーし、アクティベーション機能を提供するために使用されます。

その有用性と管理者がこれらのユニットを管理する必要がある一貫性のために、主に.serviceユニットに焦点を当てます。

ユニットファイルの構造

ユニットファイルの内部構造は、セクションで構成されています。セクションは、セクション名で囲まれた1対の角括弧「[」と「]」で示されます。各セクションは、後続のセクションの開始まで、またはファイルの終わりまで続きます。

ユニットファイルの一般的な特性

セクション名は明確に定義されており、大文字と小文字が区別されます。したがって、セクション[Unit]は、[UNIT]のように綴られている場合、notは正しく解釈されます。 systemd以外のアプリケーションによって解析される非標準セクションを追加する必要がある場合は、セクション名にX-プレフィックスを追加できます。

これらのセクション内で、ユニットの動作とメタデータは、次のように等号で示される割り当てを持つキーと値の形式を使用する単純なディレクティブを使用して定義されます。

[Section]
Directive1=value
Directive2=value

. . .

オーバーライドファイル（unit.type.dディレクトリに含まれているファイルなど）が発生した場合、ディレクティブを空の文字列に割り当てることで、ディレクティブをリセットできます。たとえば、ユニットファイルのシステムのコピーには、次のような値に設定されたディレクティブが含まれている場合があります。

Directive1=default_value

default_valueは、次のように値なしでDirective1を参照することにより、オーバーライドファイルで削除できます。

Directive1=

一般に、systemdを使用すると、簡単で柔軟な構成が可能になります。たとえば、複数のブール式が受け入れられます（肯定の場合は1、yes、on、およびtrue、肯定の場合は0、nooff）s、および反対の答えの場合はfalse）。時間はインテリジェントに解析でき、単位のない値は秒単位で想定され、内部で達成される複数の形式を組み合わせます。

[ユニット]セクションディレクティブ

ほとんどのユニットファイルにある最初のセクションは、[Unit]セクションです。これは通常、ユニットのメタデータを定義し、ユニットと他のユニットの関係を構成するために使用されます。

ファイルを解析するとき、セクションの順序はsystemdには関係ありませんが、このセクションはユニットの概要を提供するため、多くの場合、一番上に配置されます。 [Unit]セクションにある一般的なディレクティブは次のとおりです。

Description=：このディレクティブは、ユニットの名前と基本機能を説明するために使用できます。さまざまなsystemdツールによって返されるため、これを短く、具体的で、有益なものに設定することをお勧めします。
Documentation=：このディレクティブは、ドキュメント用のURIのリストの場所を提供します。これらは、内部で利用可能なmanページまたはWebアクセス可能なURLのいずれかです。 systemctl statusコマンドはこの情報を公開し、簡単に見つけられるようにします。
Requires=：このディレクティブは、このユニットが本質的に依存するユニットを一覧表示します。現在のユニットがアクティブになっている場合、ここにリストされているユニットも正常にアクティブにする必要があります。そうでない場合、このユニットは失敗します。これらのユニットは、デフォルトで現在のユニットと並行して開始されます。
Wants=：このディレクティブはRequires=に似ていますが、それほど厳密ではありません。 Systemdは、このユニットがアクティブ化されると、ここにリストされているユニットを開始しようとします。これらのユニットが見つからないか、起動に失敗した場合、現在のユニットは機能し続けます。これは、ほとんどの依存関係を構成するための推奨される方法です。繰り返しますが、これは、他のディレクティブによって変更されない限り、並列アクティベーションを意味します。
BindsTo=：このディレクティブはRequires=に似ていますが、関連するユニットが終了すると、現在のユニットも停止します。
Before=：このディレクティブにリストされているユニットは、同時にアクティブ化された場合、現在のユニットが開始済みとしてマークされるまで開始されません。これは依存関係を意味するものではなく、必要に応じて上記のディレクティブのいずれかと組み合わせて使用する必要があります。
After=：このディレクティブにリストされているユニットは、現在のユニットを開始する前に開始されます。これは依存関係を意味するものではなく、必要な場合は上記のディレクティブを使用して確立する必要があります。
Conflicts=：これは、現在のユニットと同時に実行できないユニットを一覧表示するために使用できます。この関係でユニットを起動すると、他のユニットが停止します。
Condition...=：管理者がユニットを起動する前に特定の条件をテストできるようにするConditionで始まるディレクティブがいくつかあります。これを使用して、適切なシステムでのみ実行される汎用ユニットファイルを提供できます。条件が満たされない場合、ユニットは正常にスキップされます。
Assert...=：Conditionで始まるディレクティブと同様に、これらのディレクティブは、実行環境のさまざまな側面をチェックして、ユニットをアクティブ化する必要があるかどうかを判断します。ただし、Conditionディレクティブとは異なり、否定的な結果はこのディレクティブで失敗を引き起こします。

これらのディレクティブおよび他のいくつかのディレクティブを使用して、ユニットに関する一般情報、および他のユニットおよびオペレーティングシステムとの関係を確立できます。

[インストール]セクションディレクティブ

ユニットファイルの反対側では、最後のセクションは多くの場合[Install]セクションです。このセクションはオプションであり、動作またはユニットが有効または無効になっている場合にその動作を定義するために使用されます。ユニットを有効にすると、起動時に自動的に開始されるようにマークされます。基本的に、これは、問題のユニットを、ブート時に開始されるユニットのラインのどこかにある別のユニットにラッチすることによって実現されます。

このため、有効にできるユニットのみがこのセクションを持ちます。内のディレクティブは、ユニットが有効になったときに何をすべきかを指示します。

WantedBy=：WantedBy=ディレクティブは、ユニットを有効にする方法を指定する最も一般的な方法です。このディレクティブを使用すると、Wants=ディレクティブが[Unit]セクションで行うのと同様の方法で依存関係を指定できます。違いは、この指令が補助ユニットに含まれているため、リストされているプライマリユニットが比較的きれいに保たれることです。このディレクティブを使用するユニットを有効にすると、指定したユニットにちなんで名付けられた/etc/systemd/system内にディレクトリが作成され、末尾に.wantsが追加されます。この中で、現在のユニットへのシンボリックリンクが作成され、依存関係が作成されます。たとえば、現在のユニットにWantedBy=multi-user.targetがある場合、multi-user.target.wantsというディレクトリが/etc/systemd/system内に作成され（まだ使用できない場合）、現在のユニットへのシンボリックリンクがその中に配置されます。このユニットを無効にすると、リンクが削除され、依存関係が削除されます。
RequiredBy=：このディレクティブはWantedBy=ディレクティブに非常に似ていますが、代わりに、満たされない場合にアクティブ化が失敗する原因となる必要な依存関係を指定します。有効にすると、このディレクティブを持つユニットは、.requiresで終わるディレクトリを作成します。
Alias=：このディレクティブを使用すると、ユニットを別の名前で有効にすることもできます。他の用途の中でも、これにより、関数の複数のプロバイダーが利用可能になり、関連するユニットが共通のエイリアス名のプロバイダーを検索できるようになります。
Also=：このディレクティブを使用すると、ユニットをセットとして有効または無効にできます。このユニットがアクティブなときに常に使用可能になっている必要があるサポートユニットは、ここにリストできます。これらは、インストールタスクのグループとして管理されます。
DefaultInstance=：予測できない名前のユニットインスタンスを生成する可能性のあるテンプレートユニット（後で説明）の場合、適切な名前が指定されていない場合、これを名前のフォールバック値として使用できます。

ユニット固有のセクションディレクティブ

前の2つのセクションの間に挟まれていると、ユニットタイプ固有のセクションが見つかる可能性があります。ほとんどのユニットタイプには、特定のタイプにのみ適用されるディレクティブがあります。これらは、タイプにちなんで名付けられたセクション内で利用可能です。ここでそれらについて簡単に説明します。

device、target、snapshot、およびscopeユニットタイプには、ユニット固有のディレクティブがないため、それらのタイプに関連付けられたセクションはありません。

[サービス]セクション

[Service]セクションは、サービスにのみ適用可能な構成を提供するために使用されます。

[Service]セクション内で指定する必要がある基本的なものの1つは、サービスのType=です。これは、プロセスとデーモン化動作によってサービスを分類します。これは、systemdにサービスを正しく管理し、その状態を確認する方法を指示するため、重要です。

Type=ディレクティブは、次のいずれかになります。

simple：サービスのメインプロセスはスタートラインで指定されます。これは、Type=およびBusname=ディレクティブが設定されていないが、ExecStart=が設定されている場合のデフォルトです。すべての通信は、適切なタイプの2番目のユニットを介してユニットの外部で処理する必要があります（このユニットがソケットを使用して通信する必要がある場合は、.socketユニットを介してなど）。
forking：このサービスタイプは、サービスが子プロセスをforkし、親プロセスをほぼ即座に終了するときに使用されます。これは、親が終了した場合でもプロセスがまだ実行中であることをsystemdに通知します。
oneshot：このタイプは、プロセスが短命であり、systemdが他のユニットを続行する前にプロセスが終了するのを待つ必要があることを示します。これはデフォルトのType=であり、ExecStart=は設定されていません。 1回限りのタスクに使用されます。
dbus：これは、ユニットがD-Busバスで名前を付けることを示します。これが発生すると、systemdは次のユニットの処理を続行します。
notify：これは、サービスの起動が終了したときにサービスが通知を発行することを示します。 systemdプロセスは、これが発生するのを待ってから、他のユニットに進みます。
idle：これは、すべてのジョブがディスパッチされるまでサービスが実行されないことを示します。

特定のサービスタイプを使用する場合、追加のディレクティブが必要になる場合があります。例えば：

RemainAfterExit=：このディレクティブは、一般的にoneshotタイプで使用されます。プロセスが終了した後でも、サービスがアクティブであると見なされることを示します。
PIDFile=：サービスタイプが「フォーク」としてマークされている場合、このディレクティブは、監視する必要があるメインの子のプロセスID番号を含む必要があるファイルのパスを設定するために使用されます。
BusName=：このディレクティブは、「dbus」サービスタイプを使用するときにサービスが取得しようとするD-Busバス名に設定する必要があります。
NotifyAccess=：これは、「notify」サービスタイプが選択されたときに通知をリッスンするために使用されるソケットへのアクセスを指定します。これは、「none」、「main」、または「all」のいずれかです。デフォルトの「なし」は、すべてのステータスメッセージを無視します。「メイン」オプションはメインプロセスからのメッセージをリッスンし、「すべて」オプションはサービスのコントロールグループのすべてのメンバーを処理します。

これまで、いくつかの前提条件情報について説明してきましたが、実際にサービスを管理する方法を定義していません。これを行うためのディレクティブは次のとおりです。

ExecStart=：これは、プロセスを開始するために実行されるコマンドのフルパスと引数を指定します。これは一度だけ指定できます（「oneshot」サービスを除く）。コマンドへのパスの前にダッシュ「-」文字が付いている場合、ユニットのアクティブ化に失敗のマークを付けずに、ゼロ以外の終了ステータスが受け入れられます。
ExecStartPre=：これは、メインプロセスが開始される前に実行する必要がある追加のコマンドを提供するために使用できます。これは複数回使用できます。繰り返しますが、コマンドは完全なパスを指定する必要があり、コマンドの失敗が許容されることを示すために「-」を前に付けることができます。
ExecStartPost=：これは、メインプロセスが開始されるafterで実行されるコマンドを指定することを除いて、ExecStartPre=とまったく同じ品質を持っています。
ExecReload=：このオプションのディレクティブは、利用可能な場合にサービスの構成を再ロードするために必要なコマンドを示します。
ExecStop=：これはサービスを停止するために必要なコマンドを示します。これが指定されていない場合、サービスが停止するとすぐにプロセスが強制終了されます。
ExecStopPost=：これを使用して、stopコマンドの後に実行するコマンドを指定できます。
RestartSec=：サービスの自動再起動が有効になっている場合、これはサービスの再起動を試行する前に待機する時間を指定します。
Restart=：これは、systemdがサービスを自動的に再起動しようとする状況を示します。これは、「常に」、「成功時」、「失敗時」、「異常時」、「中止時」、「ウォッチドッグ時」などの値に設定できます。これらは、サービスが停止された方法に従って再起動をトリガーします。
TimeoutSec=：これは、サービスを停止または停止するときに、サービスを失敗としてマークするか、強制的に強制終了する前に、systemdが待機する時間を設定します。 TimeoutStartSec=とTimeoutStopSec=で別々のタイムアウトを設定することもできます。

[ソケット]セクション

多くのサービスがソケットベースのアクティベーションを実装して並列化と柔軟性を向上させるため、ソケットユニットはsystemd構成で非常に一般的です。各ソケットユニットには、ソケットがアクティビティを受信したときにアクティブ化される一致するサービスユニットが必要です。

サービス自体の外部でソケット制御を解除することにより、ソケットを早期に初期化し、関連するサービスを並行して開始することができます。デフォルトでは、ソケット名は接続の受信時に同じ名前のサービスを開始しようとします。サービスが初期化されると、ソケットがサービスに渡され、バッファされた要求の処理を開始できるようになります。

実際のソケットを指定するには、次のディレクティブが一般的です。

ListenStream=：これは、順次の信頼できる通信をサポートするストリームソケットのアドレスを定義します。 TCPを使用するサービスは、このソケットタイプを使用する必要があります。
ListenDatagram=：これは、高速で信頼性の低い通信パケットをサポートするデータグラムソケットのアドレスを定義します。 UDPを使用するサービスは、このソケットタイプを設定する必要があります。
ListenSequentialPacket=：これは、メッセージの境界を保持する最大長のデータグラムを使用した、順次の信頼性の高い通信用のアドレスを定義します。これは、Unixソケットで最もよく見られます。
ListenFIFO：他のリスニングタイプとともに、ソケットの代わりにFIFOバッファを指定することもできます。

リスニングディレクティブには他にも種類がありますが、上記のものが最も一般的です。

ソケットの他の特性は、追加のディレクティブを介して制御できます。

Accept=：これは、接続ごとにサービスの追加インスタンスを開始するかどうかを決定します。 false（デフォルト）に設定すると、1つのインスタンスがすべての接続を処理します。
SocketUser=：Unixソケットでは、ソケットの所有者を指定します。これが設定されていない場合、これはrootユーザーになります。
SocketGroup=：Unixソケットでは、ソケットのグループ所有者を指定します。これも上記も設定されていない場合、これがルートグループになります。 SocketUser=のみが設定されている場合、systemdは一致するグループを見つけようとします。
SocketMode=：UnixソケットまたはFIFOバッファーの場合、これにより、作成されたエンティティのアクセス許可が設定されます。
Service=：サービス名が.socket名と一致しない場合、このディレクティブでサービスを指定できます。

[マウント]セクション

マウントユニットにより、systemd以内からマウントポイントを管理できます。マウントポイントは、変換アルゴリズムが適用された状態で、制御するディレクトリに基づいて名前が付けられます。

たとえば、先頭のスラッシュは削除され、他のすべてのスラッシュはダッシュ「-」に変換され、すべてのダッシュと印刷できない文字はCスタイルのエスケープコードに置き換えられます。この変換の結果は、マウントユニット名として使用されます。マウントユニットは、階層内でそれより上の他のマウントに暗黙的に依存します。

マウントユニットは、多くの場合、ブートプロセス中に/etc/fstabファイルから直接変換されます。自動的に作成されるユニット定義と、ユニットファイルで定義するユニット定義には、次のディレクティブが役立ちます。

What=：マウントする必要のあるリソースへの絶対パス。
Where=：リソースをマウントする必要があるマウントポイントの絶対パス。これは、従来のファイルシステム表記法を使用することを除いて、ユニットファイル名と同じである必要があります。
Type=：マウントのファイルシステムタイプ。
Options=：適用する必要のあるマウントオプション。これはカンマ区切りのリストです。
SloppyOptions=：認識されないマウントオプションがある場合にマウントが失敗するかどうかを決定するブール値。
DirectoryMode=：マウントポイント用に親ディレクトリを作成する必要がある場合、これによりこれらのディレクトリのアクセス許可モードが決まります。
TimeoutSec=：マウント操作が失敗としてマークされるまでシステムが待機する時間を設定します。

[自動マウント]セクション

このユニットを使用すると、関連する.mountユニットを起動時に自動的にマウントできます。 .mountユニットと同様に、これらのユニットには、変換されたマウントポイントのパスにちなんで名前を付ける必要があります。

[Automount]セクションは非常に単純で、次の2つのオプションのみが許可されています。

Where=：ファイルシステム上の自動マウントポイントの絶対パス。これは、変換の代わりに従来のパス表記を使用することを除いて、ファイル名と一致します。
DirectoryMode=：自動マウントポイントまたは親ディレクトリを作成する必要がある場合、これにより、これらのパスコンポーネントのアクセス許可設定が決まります。

[スワップ]セクション

スワップユニットは、システムのスワップスペースを構成するために使用されます。ユニットは、上記で説明したのと同じファイルシステム変換を使用して、スワップファイルまたはスワップデバイスにちなんで命名する必要があります。

マウントオプションと同様に、スワップユニットは/etc/fstabエントリから自動的に作成することも、専用のユニットファイルを介して構成することもできます。

ユニットファイルの[Swap]セクションには、構成用の次のディレクティブを含めることができます。

What=：これがファイルであるかデバイスであるかに関係なく、スワップスペースの場所への絶対パス。
Priority=：これは、構成されているスワップの優先順位を示す整数を取ります。
Options=：/etc/fstabファイルで通常設定されるオプションは、代わりにこのディレクティブで設定できます。コンマ区切りリストが使用されます。
TimeoutSec=：操作を失敗としてマークする前にsystemdがスワップがアクティブ化されるのを待機する時間。

[パス]セクション

パスユニットは、systmedが変更を監視できるファイルシステムパスを定義します。パスロケーションで特定のアクティビティが検出されるとアクティブになる別のユニットが存在する必要があります。パスアクティビティは、inotifyイベントを通じて決定されます。

ユニットファイルの[Path]セクションには、次のディレクティブを含めることができます。

PathExists=：このディレクティブは、問題のパスが存在するかどうかを確認するために使用されます。存在する場合、関連するユニットがアクティブになります。
PathExistsGlob=：これは上記と同じですが、パスの存在を判別するためのファイルグロブ式をサポートしています。
PathChanged=：パスの場所の変更を監視します。監視対象ファイルが閉じられたときに変更が検出されると、関連付けられたユニットがアクティブになります。
PathModified=：これは上記のディレクティブのような変更を監視しますが、ファイルの書き込み時とファイルが閉じられたときにアクティブになります。
DirectoryNotEmpty=：このディレクティブを使用すると、ディレクトリが空でなくなったときに、systemdが関連するユニットをアクティブ化できます。
Unit=：上記で指定したパス条件が満たされたときにアクティブにするユニットを指定します。これを省略すると、systemdは、このユニットと同じ基本ユニット名を共有する.serviceファイルを探します。
MakeDirectory=：これは、systemdが監視する前に問題のパスのディレクトリ構造を作成するかどうかを決定します。
DirectoryMode=：上記を有効にすると、作成する必要のあるパスコンポーネントのアクセス許可モードが設定されます。

[タイマー]セクション

タイマーユニットは、特定の時間または特定の遅延後に動作するタスクをスケジュールするために使用されます。このユニットタイプは、cronおよびatデーモンの機能の一部を置き換えるか補足します。関連するユニットを提供する必要があり、タイマーに到達するとアクティブになります。

ユニットファイルの[Timer]セクションには、次のディレクティブの一部を含めることができます。

OnActiveSec=：このディレクティブを使用すると、.timerユニットのアクティブ化に関連して関連するユニットをアクティブ化できます。
OnBootSec=：このディレクティブは、システムが起動してから、関連するユニットをアクティブ化する必要がある時間を指定するために使用されます。
OnStartupSec=：このディレクティブは上記のタイマーに似ていますが、systemdプロセス自体がいつ開始されたかに関連しています。
OnUnitActiveSec=：これは、関連付けられたユニットが最後にアクティブ化された日時に従ってタイマーを設定します。
OnUnitInactiveSec=：これは、関連付けられたユニットが最後に非アクティブとしてマークされた日時に関連してタイマーを設定します。
OnCalendar=：これにより、イベントに対して相対的ではなく絶対的を指定することにより、関連するユニットをアクティブ化できます。
AccuracySec=：この単位は、タイマーを順守する精度のレベルを設定するために使用されます。デフォルトでは、関連するユニットはタイマーに到達してから1分以内にアクティブになります。このディレクティブの値は、systemdがアクティブ化の発生をスケジュールするウィンドウの上限を決定します。
Unit=：このディレクティブは、タイマーが経過したときにアクティブ化する必要がある単位を指定するために使用されます。設定されていない場合、systemdは、このユニットに一致する名前の.serviceユニットを探します。
Persistent=：これが設定されている場合、systemdは、タイマーが非アクティブであった期間中にトリガーされた場合、タイマーがアクティブになったときに関連するユニットをトリガーします。
WakeSystem=：このディレクティブを設定すると、その状態のときにタイマーに達した場合に、システムを一時停止から復帰させることができます。

[スライス]セクション

ユニットファイルの[Slice]セクションには、実際には.sliceユニット固有の構成はありません。代わりに、上記の多くのユニットで実際に利用可能なリソース管理ディレクティブを含めることができます。

[Slice]セクションのいくつかの一般的なディレクティブは、他のユニットでも使用できますが、systemd.resource-controlのマニュアルページにあります。これらは、次のユニット固有のセクションで有効です。

[Slice]
[Scope]
[Service]
[Socket]
[Mount]
[Swap]

テンプレートユニットファイルからのインスタンスユニットの作成

このガイドの前の方で、ユニットの複数のインスタンスを作成するために使用されるテンプレートユニットファイルのアイデアについて述べました。このセクションでは、この概念について詳しく説明します。

テンプレートユニットファイルは、ほとんどの場合、通常のユニットファイルと変わりません。ただし、これらは、ファイルの特定の部分が実行時に利用可能な動的情報を利用できるようにすることで、ユニットの構成に柔軟性を提供します。

テンプレートとインスタンスユニット名

テンプレートユニットファイルは、基本ユニット名の後、ユニットタイプのサフィックスの前に@記号が含まれているため、識別できます。テンプレートユニットファイル名は次のようになります。

[email protected]

テンプレートからインスタンスを作成する場合、インスタンス識別子は、@記号とユニットタイプの開始を示すピリオドの間に配置されます。たとえば、上記のテンプレートユニットファイルを使用して、次のようなインスタンスユニットを作成できます。

[email protected]

インスタンスファイルは通常、テンプレートファイルへのシンボリックリンクとして作成され、リンク名にはインスタンス識別子が含まれます。このようにして、一意の識別子を持つ複数のリンクが単一のテンプレートファイルを指すことができます。インスタンスユニットを管理する場合、systemdは、使用するコマンドラインで指定した正確なインスタンス名を持つファイルを検索します。見つからない場合は、関連するテンプレートファイルを探します。

テンプレート指定子

テンプレートユニットファイルの威力は、主に、動作環境に応じてユニット定義内の適切な情報を動的に置換する機能によって見られます。これは、テンプレートファイル内のディレクティブを通常どおりに設定することにより行われますが、特定の値または値の一部を変数指定子に置き換えます。

以下は、インスタンスユニットが関連情報で解釈されるときに置き換えられる、より一般的な指定子の一部です。

%n：これがテンプレートファイルに表示される場所には、結果の完全なユニット名が挿入されます。
%N：これは上記と同じですが、ファイルパスパターンに存在するようなエスケープは逆になります。
%p：これはユニット名のプレフィックスを参照します。これは、@記号の前にあるユニット名の部分です。
%P：これは上記と同じですが、エスケープが逆になっています。
%i：これはインスタンス名を参照します。これはインスタンスユニットの@に続く識別子です。これは、動的であることが保証されるため、最も一般的に使用される指定子の1つです。この識別子の使用は、構成に重要な識別子の使用を促進します。たとえば、サービスが実行されるポートはインスタンス識別子として使用でき、テンプレートはこの指定子を使用してポート指定を設定できます。
%I：この指定子は上記と同じですが、エスケープが逆になっています。
%f：これは、エスケープされていないインスタンス名またはプレフィックス名に置き換えられ、先頭に/が付きます。
%c：これは、/sys/fs/cgroup/ssytemd/の標準の親階層が削除されたユニットのコントロールグループを示します。
%u：ユニットを実行するように構成されたユーザーの名前。
%U：上記と同じですが、名前ではなく数値のUIDとして使用されます。
%H：ユニットを実行しているシステムのホスト名。
%%：これはリテラルのパーセント記号を挿入するために使用されます。

テンプレートファイルで上記の識別子を使用することにより、systemdは、テンプレートを解釈してインスタンスユニットを作成するときに、正しい値を入力します。

結論

systemdを使用する場合、ユニットとユニットファイルを理解すると、管理が簡単になります。他の多くの初期化システムとは異なり、サービスまたはシステムの起動に使用される初期化ファイルを解釈するためにスクリプト言語を知っている必要はありません。ユニットファイルは、アクティベーション時のユニットの目的と効果を一目で確認できる、かなり単純な宣言構文を使用します。

アクティベーションロジックなどの機能を個別のユニットに分割すると、内部のsystemdプロセスで並列初期化を最適化できるだけでなく、構成がかなりシンプルになり、関連する接続を破棄して再構築することなく、一部のユニットを変更および再起動できます。これらの機能を活用すると、管理時の柔軟性とパワーが向上します。

TOC