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

前書き

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

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

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

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

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

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

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

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

  • ソケットベースのアクティベーション:サービスに関連付けられたソケットは、個別に処理するためにデーモン自体から分離するのが最適です。 これには、関連するソケットが最初にアクセスされるまでサービスの開始を遅らせるなど、多くの利点があります。 これにより、システムはブートプロセスの早い段階ですべてのソケットを作成できるため、関連するサービスを並行してブートできます。

  • バスベースのアクティベーション:ユニットは、 `+ D-Bus +`によって提供されるバスインターフェースでもアクティベートできます。 ユニットは、関連するバスが公開されたときに開始できます。

  • パスベースのアクティベーション:ユニットは、特定のファイルシステムパスのアクティビティまたは可用性に基づいて起動できます。 これは `+ inotify +`を利用します。

  • デバイスベースのアクティベーション: `+ udev +`イベントを活用することにより、関連するハードウェアが最初に利用可能になったときにユニットを起動することもできます。

  • 暗黙的な依存関係マッピング:ユニットのほとんどの依存関係ツリーは、 `+ systemd +`自体で構築できます。 依存関係と注文情報を追加することもできますが、ほとんどの面倒な作業は自動的に処理されます。

  • インスタンスとテンプレート:テンプレートユニットファイルを使用して、同じ一般ユニットの複数のインスタンスを作成できます。 これにより、すべてが同じ一般的な機能を提供するわずかなバリエーションまたは兄弟ユニットが可能になります。

  • 簡単なセキュリティ強化:ユニットは、単純なディレクティブを追加することで、かなり優れたセキュリティ機能を実装できます。 たとえば、ファイルシステムの一部にnoまたは読み取り専用アクセスを指定し、カーネル機能を制限し、プライベート `+ / 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 `ユニットはLinux Control Groupノードに関連付けられており、スライスに関連付けられたプロセスにリソースを制限または割り当てることができます。 名前は、 ` cgroup +`ツリー内の階層的な位置を反映しています。 ユニットは、そのタイプに応じてデフォルトで特定のスライスに配置されます。

  • * + .scope + *:スコープユニットは、バスインターフェイスから受信した情報から `+ systemd +`によって自動的に作成されます。 これらは、外部で作成されたシステムプロセスのセットを管理するために使用されます。

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

ユーティリティと、管理者がこれらのユニットを管理する必要があるため、主に「+ .service +」ユニットに焦点を当てます。

ユニットファイルの構造

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

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

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

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

[]
=
=

. . .

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

=

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

=

一般的に、 `+ systemd `は簡単で柔軟な設定を可能にします。 たとえば、複数のブール式が受け入れられます(肯定的な場合は「+1 +」、「 yes 」、「 on 」、および「 true 」、「 0 」、「 no 」、「 off +」、および「 + 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 = `ディレクティブは、ユニットを有効にする方法を指定する最も一般的な方法です。 このディレクティブにより、 ` [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 of`ユニットタイプにはユニット固有のディレクティブがないため、それらのタイプに関連するセクションはありません。

[サービス]セクション

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

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

`+ Type = +`ディレクティブは次のいずれかです:

  • シンプル:サービスのメインプロセスは開始行で指定されます。 これは、 `+ Type = `および ` Busname = `ディレクティブが設定されていないが、 ` ExecStart = `が設定されている場合のデフォルトです。 通信はユニットの外部で適切なタイプの2番目のユニットを介して処理する必要があります(このユニットがソケットを使用して通信する必要がある場合は、「。socket +」ユニットを介するなど)。

  • * forking *:このサービスタイプは、サービスが子プロセスをフォークするときに使用され、ほとんどすぐに親プロセスを終了します。 これは、親が終了してもプロセスがまだ実行中であることを「+ systemd +」に伝えます。

  • * oneshot *:このタイプは、プロセスが短命であり、 `+ systemd `がプロセスの終了を待ってから他のユニットに進むことを示します。 これはデフォルトの ` Type = `で、 ` ExecStart = +`は設定されていません。 1回限りのタスクに使用されます。

  • * dbus *:これは、ユニットがD-Busバス上で名前を取ることを示します。 この場合、 `+ systemd +`は次のユニットの処理を継続します。

  • * notify *:これは、サービスが起動を完了したときに通知を発行することを示します。 `+ systemd +`プロセスは、これが起こるのを待ってから他のユニットに進みます。

  • * idle *:これは、すべてのジョブがディスパッチされるまでサービスが実行されないことを示します。

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

  • * + RemainAfterExit = + *:このディレクティブは、一般的に `+ oneshot +`タイプで使用されます。 プロセスが終了した後でも、サービスがアクティブであると見なされることを示します。

  • * + PIDFile = + *:サービスタイプが「forking」としてマークされている場合、このディレクティブは、監視するメインの子のプロセスID番号を含むファイルのパスを設定するために使用されます。

  • * + BusName = + *:このディレクティブは、「dbus」サービスタイプを使用するときにサービスが取得を試みるD-Busバス名に設定する必要があります。

  • * + NotifyAccess = + *:これは、「notify」サービスタイプが選択されたときに通知をリッスンするために使用されるソケットへのアクセスを指定します。これは「none」、「main」、または「all」です。 デフォルトの「なし」は、すべてのステータスメッセージを無視します。 「メイン」オプションはメインプロセスからのメッセージをリッスンし、「すべて」オプションはサービスのコントロールグループのすべてのメンバーを処理します。

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

  • * + ExecStart = + *:これは、プロセスを開始するために実行されるコマンドのフルパスと引数を指定します。 これは一度だけ指定できます(「oneshot」サービスを除く)。 コマンドへのパスの前にダッシュ「-」文字が付いている場合、ユニットのアクティブ化に失敗のマークを付けずに、ゼロ以外の終了ステータスが受け入れられます。

  • * + ExecStartPre = + *:これは、メインプロセスが開始される前に実行される追加コマンドを提供するために使用できます。 これは複数回使用できます。 繰り返しますが、コマンドは完全なパスを指定する必要があり、コマンドの失敗が許容されることを示すために「-」を前に付けることができます。

  • * + ExecStartPost = + *:これは、メインプロセスが開始された後に実行されるコマンドを指定することを除いて、 `+ ExecStartPre = +`とまったく同じ品質を持ちます。

  • * + ExecReload = + *:このオプションのディレクティブは、利用可能な場合、サービスの設定をリロードするために必要なコマンドを示します。

  • * + ExecStop = + *:これは、サービスを停止するために必要なコマンドを示します。 これが指定されていない場合、サービスが停止するとすぐにプロセスが強制終了されます。

  • * + ExecStopPost = + *:これは、停止コマンドに続いて実行するコマンドを指定するために使用できます。

  • * + 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 = + *:自動マウントポイントまたは親ディレクトリを作成する必要がある場合、これらのパスコンポーネントの権限設定が決定されます。

[Swap]セクション

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

マウントオプションと同様に、スワップユニットは `+ / 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 +`のマニュアルページで見つけることができます。 これらは、次のユニット固有のセクションで有効です。

  • + [スライス] +

  • + [スコープ] +

  • + [サービス] +

  • + [ソケット] +

  • + [マウント] +

  • + [スワップ] +

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

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

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

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

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

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

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

テンプレート指定子

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

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

  • * +%n + *:テンプレートファイルでこれが現れる場所には、結果の完全なユニット名が挿入されます。

  • * +%N + *:これは上記と同じですが、ファイルパスパターンに存在するようなエスケープはすべて元に戻ります。

  • * +%p + *:これはユニット名のプレフィックスを参照します。 これは、ユニット名のうち「+ @ +」記号の前に来る部分です。

  • * +%P + *:これは上記と同じですが、エスケープが逆になります。

  • * +%i + *:これはインスタンス名を参照します。これは、インスタンス単位の `+ @ +`に続く識別子です。 これは、動的であることが保証されるため、最も一般的に使用される指定子の1つです。 この識別子の使用は、構成に重要な識別子の使用を促進します。 たとえば、サービスが実行されるポートはインスタンス識別子として使用でき、テンプレートはこの指定子を使用してポート指定を設定できます。

  • * +%I + *:この指定子は上記と同じですが、エスケープが逆になります。

  • * +%f + *:これは、エスケープされていないインスタンス名またはプレフィックス名に置き換えられ、先頭に「+ / +」が付きます。

  • * +%c + *:これは、ユニットの制御グループを示し、標準の親階層である `+ / sys / fs / cgroup / ssytemd / +`が削除されます。

  • * +%u + *:ユニットを実行するように設定されたユーザーの名前。

  • * +%U + *:上記と同じですが、名前ではなく数値の「+ UID +」として。

  • * +%H + *:ユニットを実行しているシステムのホスト名。

  • * + %% + *:これは、リテラルのパーセント記号を挿入するために使用されます。

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

結論

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

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

前の投稿:FreeBSD 10.1にOSSECをインストールおよび構成する方法
次の投稿:Debian 9でのサーバーの初期セットアップ