SystemdUnitsとUnitFilesを理解する

序章

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

の 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. この場所のファイルには、前者の場所よりも重みが少なくなりますが、後者の場所よりも重みが大きくなります。

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

ユニットの種類

Systemd 記述しているリソースのタイプに応じてユニットを分類します。 ユニットのタイプを判別する最も簡単な方法は、リソース名の末尾に追加されるタイプ接尾辞を使用することです。 次のリストは、 systemd:

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

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

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

ユニットファイルの構造

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

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

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

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

[Section]
Directive1=value
Directive2=value

. . .

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

Directive1=default_value

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

Directive1=

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

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

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

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

• Description = ：このディレクティブは、ユニットの名前と基本機能を説明するために使用できます。 様々な方から返送されます systemd ツールなので、これを短く、具体的で、有益なものに設定することをお勧めします。
• Documentation = ：このディレクティブは、ドキュメント用のURIのリストの場所を提供します。 これらは内部で利用可能です man ページまたはWebアクセス可能なURL。 The systemctl status コマンドはこの情報を公開し、簡単に発見できるようにします。
• Requireds = ：このディレクティブは、このユニットが本質的に依存しているユニットを一覧表示します。 現在のユニットがアクティブ化されている場合、ここにリストされているユニットも正常にアクティブ化されている必要があります。そうでない場合、このユニットは失敗します。 これらのユニットは、デフォルトで現在のユニットと並行して開始されます。
• Wants = ：このディレクティブは次のようになります Requires=、ただし厳密ではありません。 Systemd このユニットがアクティブになると、ここにリストされているユニットを起動しようとします。 これらのユニットが見つからないか、起動に失敗した場合、現在のユニットは引き続き機能します。 これは、ほとんどの依存関係を構成するための推奨される方法です。 繰り返しますが、これは、他のディレクティブによって変更されない限り、並列アクティブ化を意味します。
• BindingsTo = ：このディレクティブは次のようになります Requires=、ただし、関連するユニットが終了すると、現在のユニットも停止します。
• Before = ：このディレクティブにリストされているユニットは、同時にアクティブ化された場合、現在のユニットが開始済みとしてマークされるまで開始されません。 これは依存関係を意味するものではなく、必要に応じて上記のディレクティブの1つと組み合わせて使用する必要があります。
• 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つのセクションに挟まれて、ユニットタイプ固有のセクションが見つかる可能性があります。 ほとんどのユニットタイプは、特定のタイプにのみ適用されるディレクティブを提供します。 これらは、タイプにちなんで名付けられたセクション内で利用できます。 ここではそれらについて簡単に説明します。

The device, target, snapshot、 と scope ユニットタイプにはユニット固有のディレクティブがないため、そのタイプに関連するセクションはありません。

[サービス]セクション

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

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

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

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

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

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

[スワップ]セクション

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

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

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

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

[パス]セクション

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

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

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

[タイマー]セクション

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

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

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

[スライス]セクション

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

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

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

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

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

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

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

テンプレートユニットファイルには、 @ 基本ユニット名の後、ユニットタイプの接尾辞の前の記号。 テンプレートユニットのファイル名は次のようになります。

example@.service

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

example@instance1.service

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

テンプレート指定子

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

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

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

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

結論

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

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