SystemdUnitsとUnitFilesを理解する

序章

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

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

このガイドでは、systemdが処理できるさまざまなユニットを紹介します。また、これらのリソースがシステムで処理される方法を形作るために、ユニットファイルで使用できる多くのディレクティブのいくつかについても説明します。

Systemdユニットはあなたに何を与えますか？

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

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

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

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

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

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ユニットはLinuxControl Groupノードに関連付けられており、リソースを制限したり、スライスに関連付けられたプロセスに割り当てたりすることができます。この名前は、cgroupツリー内の階層的な位置を反映しています。ユニットは、タイプに応じて、デフォルトで特定のスライスに配置されます。
.scope ：スコープユニットは、バスインターフェイスから受信した情報からsystemdによって自動的に作成されます。これらは、外部で作成された一連のシステムプロセスを管理するために使用されます。

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

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

ユニットファイルの構造

ユニットファイルの内部構造はセクションで構成されています。セクションは、セクション名が囲まれた「[」と「]」のペアで示されます。各セクションは、次のセクションの先頭またはファイルの末尾まで拡張されます。

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

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

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

[Section]
Directive1=value
Directive2=value

. . .

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

Directive1=default_value

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

Directive1=

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

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

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

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

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

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

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

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

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

WantedBy = ：WantedBy=ディレクティブは、ユニットを有効にする方法を指定する最も一般的な方法です。このディレクティブを使用すると、[Unit]セクションのWants=ディレクティブと同様の方法で依存関係を指定できます。違いは、このディレクティブが補助ユニットに含まれているため、リストされているプライマリユニットを比較的クリーンな状態に保つことができることです。このディレクティブが有効になっているユニットを有効にすると、指定したユニットにちなんで名付けられた/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バス名に設定する必要があります。
NotificationAccess = ：これは、「notify」サービスタイプが選択されたときに通知をリッスンするために使用されるソケットへのアクセスを指定します。これは、「none」、「main」、または「all」です。デフォルトの「none」は、すべてのステータスメッセージを無視します。「main」オプションはメインプロセスからのメッセージをリッスンし、「all」オプションはサービスのコントロールグループのすべてのメンバーを処理させます。

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

ExecStart = ：これは、プロセスを開始するために実行されるコマンドのフルパスと引数を指定します。これは一度だけ指定できます（「ワンショット」サービスを除く）。コマンドへのパスの前にダッシュ「-」文字が付いている場合、ユニットのアクティブ化を失敗としてマークせずに、ゼロ以外の終了ステータスが受け入れられます。
ExecStartPre = ：これを使用して、メインプロセスを開始する前に実行する必要がある追加のコマンドを提供できます。これは複数回使用できます。この場合も、コマンドはフルパスを指定する必要があり、コマンドの失敗が許容されることを示すために、コマンドの前に「-」を付けることができます。
ExecStartPost = ：これはExecStartPre=とまったく同じ品質ですが、メインプロセスの開始後に実行されるコマンドを指定する点が異なります。
ExecReload = ：このオプションのディレクティブは、使用可能な場合にサービスの構成をリロードするために必要なコマンドを示します。
ExecStop = ：これはサービスを停止するために必要なコマンドを示します。これが指定されていない場合、サービスが停止するとすぐにプロセスが強制終了されます。
ExecStopPost = ：これを使用して、停止コマンドの後に実行するコマンドを指定できます。
ResetSec = ：サービスの自動再起動が有効になっている場合、これはサービスの再起動を試行する前に待機する時間を指定します。
Reset = ：これは、systemdがサービスを自動的に再起動しようとする状況を示します。これは、「always」、「on-success」、「on-failure」、「on-abnormal」、「on-abort」、「on-watchdog」などの値に設定できます。これらは、サービスが停止された方法に従って再起動をトリガーします。
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を使用する場合、ユニットとユニットファイルを理解すると、管理が容易になります。他の多くのinitシステムとは異なり、サービスやシステムの起動に使用されるinitファイルを解釈するためにスクリプト言語を知っている必要はありません。ユニットファイルは、アクティブ化時のユニットの目的と効果を一目で確認できる、かなり単純な宣言型構文を使用しています。

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