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

序章

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

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

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

Systemd Units は何を提供しますか?

ユニットは、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 ユニットは Linux コントロールグループノードに関連付けられており、リソースを制限したり、スライスに関連付けられたプロセスに割り当てたりすることができます。この名前は、cgroup ツリー内の階層的な位置を反映しています。ユニットは、そのタイプに応じて、デフォルトで特定のスライスに配置されます。

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

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

.service ユニットの有用性と、管理者がこれらのユニットを管理するために必要な一貫性のために、主に .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 コマンドはこの情報を公開し、簡単に見つけられるようにします。
Requires=: このディレクティブは、このユニットが基本的に依存しているすべてのユニットをリストします。現在のユニットがアクティブ化されている場合、ここにリストされているユニットも正常にアクティブ化する必要があります。そうでない場合、このユニットは失敗します。これらのユニットは、デフォルトで現在のユニットと並行して開始されます。
Wants=: このディレクティブは Requires= に似ていますが、それほど厳密ではありません。 Systemd は、このユニットがアクティブ化されると、ここにリストされているユニットを起動しようとします。これらのユニットが見つからないか、起動に失敗した場合、現在のユニットは引き続き機能します。これは、ほとんどの依存関係を構成するための推奨される方法です。繰り返しになりますが、これは、他のディレクティブによって変更されない限り、並列アクティベーションを意味します。
BindsTo=: このディレクティブは Requires= に似ていますが、関連するユニットが終了すると現在のユニットも停止します。
Before=: このディレクティブにリストされているユニットは、同時にアクティブ化された場合、現在のユニットが開始済みとしてマークされるまで開始されません。これは依存関係を意味するものではなく、必要に応じて上記のディレクティブのいずれかと組み合わせて使用する必要があります。
After=: このディレクティブにリストされているユニットは、現在のユニットを開始する前に開始されます。これは依存関係を意味するものではなく、必要な場合は上記のディレクティブを通じて確立する必要があります。
Conflicts=: 現在のユニットと同時に実行できないユニットを一覧表示するために使用できます。この関係でユニットを開始すると、他のユニットが停止します。
Condition...=: Condition で始まる多くのディレクティブがあり、管理者はユニットを開始する前に特定の条件をテストできます。これは、適切なシステムでのみ実行される汎用ユニットファイルを提供するために使用できます。条件が満たされない場合、ユニットは正常にスキップされます。
Assert...=: Condition で始まるディレクティブと同様に、これらのディレクティブは実行環境のさまざまな側面をチェックして、ユニットをアクティブにするかどうかを決定します。ただし、Condition ディレクティブとは異なり、否定的な結果はこのディレクティブで失敗します。

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

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

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

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

WantedBy=: WantedBy= ディレクティブは、ユニットを有効にする方法を指定する最も一般的な方法です。このディレクティブを使用すると、[Unit] セクションで Wants= ディレクティブが行うのと同様の方法で依存関係を指定できます。違いは、このディレクティブが補助ユニットに含まれているため、リストされているプライマリユニットを比較的クリーンな状態に保つことができます。このディレクティブを持つユニットが有効になると、指定されたユニットの名前に .wants が追加された名前の /etc/systemd/system 内にディレクトリが作成されます。この中に、現在のユニットへのシンボリックリンクが作成され、依存関係が作成されます。たとえば、現在のユニットに 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=: サービスタイプが \forking としてマークされている場合、このディレクティブは、メインの子のプロセス ID 番号を含むファイルのパスを設定するために使用されます。監視されています。
BusName=: このディレクティブは、\dbus サービスタイプの使用時にサービスが取得しようとする D-Bus バス名に設定する必要があります。
NotifyAccess=: \notify サービスタイプが選択されている場合に通知をリッスンするために使用する必要があるソケットへのアクセスを指定します。これは、\none、\main、または「すべて。デフォルトの \none は、すべてのステータスメッセージを無視します。\main オプションは、メインプロセスからのメッセージをリッスンし、\all オプションは、サービスのコントロールグループのすべてのメンバーを処理します。

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

ExecStart=: プロセスを開始するために実行するコマンドのフルパスと引数を指定します。これは 1 回だけ指定できます (\oneshot サービスを除く)。コマンドへのパスの前にダッシュ \- 文字がある場合、ユニットのアクティブ化を失敗としてマークすることなく、ゼロ以外の終了ステータスが受け入れられます。 /li>
ExecStartPre=: これは、メインプロセスが開始される前に実行する必要がある追加のコマンドを提供するために使用できます。これは複数回使用できます。ここでも、コマンドはフルパスを指定する必要があり、コマンドの失敗が許容されることを示すために \- を先頭に付けることができます。
ExecStartPost=: これは ExecStartPre= とまったく同じ性質を持っていますが、メインプロセスの後に実行されるコマンドを指定する点が異なります。開始しました。
ExecReload=: このオプションのディレクティブは、利用可能な場合にサービスの構成をリロードするために必要なコマンドを示します。
ExecStop=: サービスを停止するために必要なコマンドを示します。これが指定されていない場合、サービスが停止すると、プロセスはすぐに強制終了されます。
ExecStopPost=: これは、停止コマンドに続いて実行するコマンドを指定するために使用できます。
RestartSec=: サービスの自動再起動が有効になっている場合、サービスの再起動を試みるまでの待機時間を指定します。
Restart=: これは、systemd がサービスを自動的に再起動しようとする状況を示します。これは、\always、\on-success、\on-failure、\on-abnormal、\on-abort、\on-watchdog などの値に設定できます。これらは、サービスが停止された方法に従って再起動をトリガーします。
TimeoutSec=: サービスを停止または停止するときに、サービスを失敗としてマークするか強制終了する前に、systemd が待機する時間を構成します。 TimeoutStartSec= と TimeoutStopSec= で別々のタイムアウトを設定することもできます。

[Socket] セクション

多くのサービスがソケットベースのアクティベーションを実装して、より優れた並列化と柔軟性を提供するため、ソケットユニットは 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=: マウント操作が失敗としてマークされるまでシステムが待機する時間を構成します。

[Automount] セクション

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

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

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

[スワップ] セクション

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

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

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

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

[Path] セクション

パスユニットは、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 man ページにあります。これらは、次のユニット固有のセクションで有効です。

[スライス]
[スコープ]
[サービス]
[ソケット]
[マウント]
[スワップ]

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

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

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

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

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

example@.service

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

example@instance1.service

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

テンプレート指定子

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

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

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

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

結論

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

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

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

序章