Index · Directives · Python · libudev · gudev systemd 210
systemd.unit — ユニット設定
service.service, socket.socket, device.device, mount.mount, automount.automount, swap.swap, target.target, path.path, timer.timer, snapshot.snapshot, slice.slice, scope.scope
/etc/systemd/system/*
/run/systemd/system/*
/usr/lib/systemd/system/*
...
$HOME/.config/systemd/user/*
/etc/systemd/user/*
/run/systemd/user/*
/usr/lib/systemd/user/*
...
ユニット設定ファイルは、サービス、ソケット、デバイス、マウントポイント、オートマウントポイント、スワップファイルあるいはパーティション、開始ターゲット、監視対象のファイルシステムパス、systemd(1) が制御、監視するタイマー、システム状態の一時的なスナップショット、資源管理スライス、そして外部で作成されたプロセスのグループに関する情報をエンコードする。そのシンタックスは、XDG Desktop Entry Specification.desktop ファイルの影響を受けている。なお、後者は Microsoft Windows .ini ファイルの影響を受けている。
このマニュアルページはすべてのユニットタイプに共通の設定オプションをリストする。これらのオプションは、ユニットファイルの [Unit] あるいは [Install] セクションに書く必要がある。
ここで説明する一般的な [Unit] と [Install] セクション以外に、それぞれのユニットは、タイプ固有のセクションを持つことがある。例えば、サービスユニットは、 [Service] を持つ。詳しくは、それぞれのマニュアルページを参照のこと： systemd.service(5), systemd.socket(5), systemd.device(5), systemd.mount(5), systemd.automount(5), systemd.swap(5), systemd.target(5), systemd.path(5), systemd.timer(5), systemd.snapshot(5). systemd.slice(5). systemd.scope(5).
複数回指定することができる設定がある。そのときの解釈は、設定によって違う。多くの場合、リストからの複数の設定や、空の値、"resets" に設定するときは、以前の設定を無視することになる。この指定が可能なときは、設定の説明にそう書いてある。なお、同じ値に複数回設定をすると、ユニットファイルは XDG .desktop ファイル形式のパーサーと互換でなくなることに注意。
ユニットファイルは、次のセクションで説明する、コンパイル時に決まる複数のパスからロードされる。
ユニットファイルはここでリストするオプション以外のものを含んでもよい。systemd が知らないオプションを見つけたら、警告ログメッセージを出すが、ユニットのロードは続ける。オプションが、X- でプレフィックスされている場合、systemd は完全にそれを無視する。アプリケーションはこれを使って、ユニットファイルに追加の情報を含めることができる。
ユニットファイルで使われるブール引数は、いろいろな形式の書き方ができる。真の設定値として、1, yes, true そして on 文字列は同じである。偽の設定値として、0, no, false そして off 文字列は同じである。
ユニットファイルで使われる時間間隔の値は、いろいろな形式の書き方ができる。単独の数字は秒数を示す。時間の単位が後についたものは、その単位となる。単位のついた複数の値の連結もサポートされ、値の和となる。例。"50" は ５０ 秒。"2min 200ms" は、２分と２００ミリ秒、つまり、 120200ms。以下の時間単位が理解される。s, min, h, d, w, ms, us。詳しくは、systemd.time(7) を参照。
空の行と、# あるいは ; で始まる行は無視される。これはコメントに使える。バックスラッシュで終わる行は、読む時に次の行と結合され、バックスラッシュは空白文字に置換される。これは長い行をラップするのに使える。
ユニットファイル foo.service に対して、foo.service.wants/ ディレクトリがあることもある。そのディレクトリからシンボリックリンクされたすべてのユニットファイルは、暗黙的に元のユニットの Wanted= タイプ依存として追加される。これは、ユニットファイルを変更せずにあるユニットを他のユニットの開始時にフックする便利な方法である。Wanted= のセマンティクスの詳細は、以下を参照。.wants/ ディレクトリにシンボリックリンクを作る推奨される方法は、systemctl(1) ツールの enable コマンドである。それは、ユニットファイルの [Install] セクション（以下を参照。）から情報を読む。Requires= タイプ依存にも似た機能がある。その場合、ディレクトリサフィックスは、 .requires/ である。
ユニットファイル foo.service に対して、foo.service.d/ ディレクトリがあることもある。そのディレクトリにある、サフィックス ".conf" を持つすべてのファイルは、元のファイルが解析された後、解析される。これは、ユニットファイルを変更せずにあるユニットの設定を変更あるいは追加する便利な方法である。インクルードされるファイルは、設定の前に適切なセクションヘッダがなくてはいけないことに注意。
systemd はユニット間に柔軟な依存関係システムを提供するが、この機能の使用はほどほどにとどめ、バスあるいはソケットベースのアクティベーションなどの技術を使うのをおすすめする。後者は依存関係を暗黙的にし、よりシンプルで柔軟なシステムを可能とする。
ユニット名には、ファイルシステム名前空間にあるパスを反映するものがある。例。デバイスユニット dev-sda.device は、ファイルシステム名前空間のデバイスノード /dev/sda を持つデバイスのことである。こういう場合、パス名をエスケープして、結果をファイル名の一部として使うことができるように特別の方法が使われる。基本的に、パス名にある "/" は "-" に置換され、すべての印字不可能文字と "-" は、C スタイルの "\x20" エスケープになる。ルートディレクトリ "/" は、単独のダッシュでエンコードされ、それ以外の最初と最後の "/" は変換中にすべてのパスから除かれる。このエスケープは可逆である。
ユニットを実行時にテンプレートファイルから実現するオプションもある。これにより、１つの設定ファイルから複数のユニットを作成できる。systemd がユニット設定ファイルを探すとき、まず、ファイルシステムでユニット名そのものを探す。それがなく、ユニット名に "@" 文字が含まれる場合、systemd は同じ名前だが、インスタンス文字列（つまり、"@" 文字とサフィックスの間の部分）を除いたユニットテンプレートを探す。例。サービス getty@tty3.service が要求され、その名前のファイルがないとき、systemd は getty@.service を探して、見つかったらその設定ファイルからサービスを実行する。
設定ファイルの中からインスタンス文字列を参照するとき、多くの設定オプションにおいて、特別の "%i" specifier を使うことができる。詳しくは以下を参照。
ユニットファイルが空（つまり、ファイル長が０）であるか、/dev/null にシンボリックリンクされているとき、その設定はロードされず、ロード状態は "masked" と表示され、アクティベートすることはできない。これは、ユニットを完全に無効にし、手作業によっても開始できなくするための効率のよい方法として使える。
ユニットファイルフォーマットは、Interface Stability Promise の対象である。
ユニットファイルは、以下の２つの表に示す、コンパイル時に決まる複数のパスからロードされる。リストの最初の方にあるディレクトリにあるユニットファイルは、リストの下の方にあるディレクトリにある同じ名前のファイルより優先される。
systemd がユーザーモード(--user) で実行しており、変数 $SYSTEMD_UNIT_PATH が設定されているとき、この変数の値は、ユニットロードパスより優先される。
Table 1. システムモード(--system)で実行中のときのロードパス
Table 2. ユーザモード(--user)で実行中のときのロードパス
ユニットロードパスにあるディレクトリ以外のディレクトリから追加のユニットが systemd にロードされる ("linked")ことがある。systemctl(1) の link コマンドを参照。また、 Generator によってダイナミックに作成されるユニットもある。
ユニットファイルは [Unit] セクションを持つことがある。それは、ユニットタイプによらない一般的なユニットの情報を持つ。
Description=¶
ユニットを説明する自由形式の文字列。これは、ユニット名とともにその説明を表示する UI での使用のためにある。説明は、エンドユーザーに理解できるなんらかの名前を含むべきである。"Apache2 Web Server" は良い例である。悪い例は、 "high-performance light-weight HTTP server" （一般的過ぎる）あるいは、 "Apache2" (狭すぎるし、Apache を知らない人には意味不明)。
Documentation=¶
このユニットあるいはその設定についての文書を参照する、空白で区切られた URI のリスト。"http://", "https://", "file:", "info:", "man:" のタイプの URI だけが許される。これらの URI のシンタックスについて詳しくは、uri(7) を参照。URI は、最も関連があるものを最初にして、関連性の順にリストされること。まず最初にそのユニットの目的がなんであるかを説明する文書をあげ、次のその設定の仕方、そして次にそれ以外の関連する文書をあげるのはよい考えである。このオプションは一度以上指定することができ、指定された URI のリストはマージされる。空文字列を指定すると、リストはリセットされ、以前の設定は無効となる。
Requires=¶
他のユニットに対する requirement 依存を指定する。このユニットがアクティベートされたとき、ここにリストされるユニットもアクティベートされる。他のユニットの１つがデアクティベートされたり、アクティベーションが失敗した場合、このユニットはデアクティベートされる。このオプションは一度以上指定することができる。あるいは、空白で区切られた複数のユニットが１つのオプションで指定できる。その場合、リストされたすべてのユニットへの requirement 依存が作成される。なお、 requirement 依存はサービスが開始、終了する順序に影響を与えないことに注意。これは、After= と Before= オプションで独立して設定が必要である。ユニット foo.service がユニット bar.service を、 Requires= 設定で必要としていて、After= と Before= で順序が指定されていない場合、foo.service がアクティベートされるとき、両方のユニットが同時に、相互の間に遅延なく、開始される。サービスが失敗しても強靭なシステムにするには、Requires= の代わりに Wants= を使う方がよいことがある。
なお、以前に述べたように、このタイプの依存は、ユニット設定ファイルの外で、そのユニットファイルに関連したディレクトリに .requires/ シンボリックリンクを追加しても得ることができる。
RequiresOverridable=¶
Requires= に似ている。ユーザーがあらわに開始を要求した場合、RequiresOverridable= にリストされた依存関係のうち、満たすことのできないものや開始に失敗したものは無視される。ユーザーの要求によらないユニットの自動開始、あるいは他の依存関係によって暗黙的にプルインされた場合の開始ならば、この依存関係は満たされる必要があり、そうでない場合はトランザクションは失敗する。つまり、このオプションは、通常は守られるが、ユーザーがあらわにユニットを開始した場合には成功も失敗も関係ないという依存関係を設定するために使うことができる。
Requisite=, RequisiteOverridable=¶
それぞれ、Requires= と RequiresOverridable= に似ている。しかし、ここにリストされたユニットが既に開始していない場合、それらは開始されず、トランザクションは直ちに失敗する。
Wants=¶
Requires= のより弱いバージョン。このユニットが開始するとき、このオプションにリストされるユニットは開始される。しかし、リストされたユニットが開始に失敗したり、トランザクションに追加できなかった場合、トランザクション全体の有効性には影響を与えない。これは、あるユニットの開始に他のユニットの開始をフックするおすすめの方法である。
このタイプの依存関係は、ユニット設定ファイルの外側でも、そのユニットファイルに対応する .wants/ ディレクトリにシンボリックリンクを追加することによって実現することもできることに注意。詳しくは、以前の記述を参照。
BindsTo=¶
requirement 依存を決める。Requires= と形式はとても似ている。しかしその他にこの設定は、リストにあるユニットのいずれかが突然消えたら、このユニットは停止されることを宣言する。ユニットは、サービスが自分から終了したり、デバイスがアンプラグされたり、マウントポイントが systemd の介入なしにアンマウントされたりするとき、突然、予期されずに消えることがある。
PartOf=¶
Requires= に似た依存を決める。しかし、ユニットの停止と再開始だけに限定される。systemd がここにリストされたユニットを停止あるいは再開始するとき、アクションはこのユニットに伝搬する。これは、一方通行の依存であることに注意。このユニットの変化はリストされたユニットには影響しない。
Conflicts=¶
空白で区切られたユニット名のリスト。負の requirement 依存を設定する。あるユニットが他のユニットに Conflicts= 設定を持つとき、前者を開始すると後者は停止する。逆も同じ。なお、この設定は、After= と Before= ordering 依存とは独立で直交していることに注意。
ユニット B と conflict するユニット A が、B と同じ時に開始するようにスケジュールされたとき、トランザクションは失敗する（両方がトランザクションの必要な部分の場合）か、修正される（片方あるいは両方がトランザクションの必要な部分でない場合）かのいずれかである。後者の場合、必要でないジョブは削除される。両方とも必要でない場合、conflict するユニットは開始され、conflict されるユニットは停止される。
Before=, After=¶
空白で区切られたユニット名のリスト。ユニット間の ordering 依存を決める。ユニット foo.service が Before=bar.service 指定を含み、両方のユニットが開始するとき、bar.service の開始は、foo.service が開始するまで待たされる。なお、この設定は、Requires= で設定される requirement 依存とは独立で直交していることに注意。After= と Requires= の両方に同じユニット名を入れるのはよくあるパターンである。その場合、リストにあるユニットはこれらのオプションを持つユニットより先に開始する。このオプションは一度以上指定することができ、その場合、リストされたすべてのユニットへの ordering 依存が作成される。After= は Before= の逆である。つまり、After= は設定のあるユニットがリストされたユニットが開始し終わった後に開始するのを保証する。Before= は逆、つまり、設定のあるユニットはリストされたユニットが開始する前に完全に開始し終わっているのを保証する。なお、 ordering 依存のある２つのユニットがシャットダウンするときは、開始順の逆が適用されるのに注意。つまり、あるユニットが他のユニットの After= 指定を持つ場合、両方をシャットダウンするときは、前者が後者より前に停止する。あるユニットが他のユニットに ordering 依存を持ち、シャットダウンするときに、後者が開始してきたら、 ordering 依存が After= でも Before= でも関係なく、シャットダウンは開始の前に順序付けられる。２つのユニットが ordering 依存を持たないで、同時にシャットダウンあるいは開始するとき、順序付けは何もされない。
OnFailure=¶
空白で区切られたつ以上のユニットのリストであり、それらはこのユニットが "failed" 状態に入った時にアクティベートされる。
PropagatesReloadTo=, ReloadPropagatedFrom=¶
空白で区切られた１つ以上のユニットのリストであり、それぞれ、元のユニットへのリロード要求がリストのユニットに伝搬されるか、リストのユニットへのリロード要求が元のユニットに伝搬される。あるユニットにリロード要求を出すと、この２つの設定によってリロード要求を伝搬するべきすべてのユニットへのリロード要求が自動的にエンキューされる。
JoinsNamespaceOf=¶
プロセスを開始するユニット（サービスユニットのように）で使われ、１つ以上の他のユニットを指定する。プロセスは、そのネットワークそして／あるいは一時ファイルの名前空間に加わる。これは、PrivateNetwork= と PrivateTmp= 設定をサポートするユニットタイプだけに有効である。（詳しくは、systemd.exec(5) を参照。）この設定がされているユニットが開始するとき、そのプロセスは、リストにある開始されたユニットと同じ /tmp, /var/tmp そしてネットワーク名前空間を見る。リストにあるユニットが複数個、既に開始されていた場合、どの名前空間が使われるのかは未定義である。この設定は、名前空間に加わるユニットと、加わられるユニットの両方に PrivateNetwork= そして／あるいは PrivateTmp= が有効の時だけ、効果があることに注意。
RequiresMountsFor=¶
空白で区切られた絶対パスのリスト。指定されたパスをアクセスするために必要なすべてのマウントユニットに対する Requires= と After= タイプの依存が自動的に追加される。
OnFailureJobMode=¶
"fail", "replace", "replace-irreversibly", "isolate", "flush", "ignore-dependencies" あるいは "ignore-requirements" のいずれかの値を取る。デフォルト値は "replace"。OnFailure= にリストしたユニットがどのようにエンキューされるかを指定する。それぞれの値の詳細は、systemctl(1) の --job-mode= オプションを参照。これが "isolate" のときは、OnFailure= には１つのユニットしか書けない。
IgnoreOnIsolate=¶
ブール引数を取る。true なら、このユニットは他のユニットを isolate するときにも停止されない。デフォルト値は false。
IgnoreOnSnapshot=¶
ブール引数を取る。true なら、このユニットはスナップショットに含まれない。デバイスユニットとスナップショットユニットのデフォルト値は true。他のユニットは false。
StopWhenUnneeded=¶
ブール引数を取る。true なら、このユニットは使われなくなったら停止される。作業を最小にするために、デフォルトでは systemd はユニットが他のユニットと競合するかあるいは、ユーザーがあらわにシャットダウンを要求する時以外ではユニットを停止しない。このオプションが有効の時、ユニットは、他のアクティブユニットがそれを必要としない時には自動的にクリーンアップされる。デフォルト値は false。
RefuseManualStart=, RefuseManualStop=¶
ブール引数を取る。true なら、このユニットは間接的にしかアクティベートあるいはデアクティベートできない。この場合、ユーザーによるあらわな開始、終了要求は拒否される。他のユニットの依存関係による開始あるいは停止は成功する。これは主に、ユーザーが誤って、あらわにアクティベートするべきでないものをしたり、デアクティベートするべきでないものをしたりするのを防止するための安全対策である。デフォルト値は false。
AllowIsolate=¶
ブール引数を取る。true なら、このユニットは systemctl isolate で使うことができる。そうでないときは拒否される。SysV init システムで使われるランレベルのように使われるターゲットユニット以外には、これは無効にしておく方が、システム状態を不安定にしないためにはよい考えである。デフォルトは false。
DefaultDependencies=¶
ブール引数を取る。true （デフォルト）なら、このユニットに対してのデフォルトの依存関係がいくつか暗黙的に作成される。実際に作られる依存関係はユニットタイプに依存する。例えば、サービスユニットなら、これらの依存関係は、そのサービスが基本的なシステム初期化が完了した後に開始し、システムシャットダウンの時には適切に終了することを保証する。詳しくは、それぞれのマニュアルページを参照。一般的には、 early boot あるいは late shutdown に関連するサービスだけが、これを false にするのがよい。大多数の普通のユニットでは、このオプションを有効のままにするのを強くおすすめする。 false にした場合、すべての暗黙的依存関係が無効になるわけではない。必須でないものだけである。
JobTimeoutSec=¶
クライアントがこのユニットのジョブの完了を待っているとき、ここで指定された時間の後、タイムアウトする。この期限が来たら、ジョブはキャンセルされる。しかし、ユニットは状態を変えないし、"failed" モードに入ることもない。デフォルト値は０（ジョブはタイムアウトしない。）ただし、デバイスユニットは除く。注意：このタイムアウトは、ユニット固有のタイムアウト（例えば、サービスユニットにある Timeout= 指定）とは無関係である。なぜならば、ジョブのタイムアウトは、ユニット自身には影響を与えない。それを待っているジョブがあればそれに影響を与えるだけである。別の言葉で言えば、ユニット固有のタイムアウトは、ユニット状態の変更を中断し、元に戻すために使うことができる。このオプションで設定できるジョブのタイムアウトは、ユニット状態が変わるのを待っているジョブを中断するためにだけ、使うことができる。
ConditionArchitecture=, ConditionVirtualization=, ConditionHost=, ConditionKernelCommandLine=, ConditionSecurity=, ConditionCapability=, ConditionACPower=, ConditionPathExists=, ConditionPathExistsGlob=, ConditionPathIsDirectory=, ConditionPathIsSymbolicLink=, ConditionPathIsMountPoint=, ConditionPathIsReadWrite=, ConditionDirectoryNotEmpty=, ConditionFileNotEmpty=, ConditionFileIsExecutable=, ConditionNull=¶
ユニットを開始する前に、指定の条件が真であるかを確認する。真でない場合、ユニットの開始はスキップされる。なお、それに関するすべての ordering 依存は順守される。条件が失敗しても、ユニットは failed 状態にはならない。条件は、キューされた開始ジョブが実行される時に評価される。
ConditionArchitecture= は、システムが特定のアーキテクチャ上で実行しているかをチェックするのに使う。 x86, x86-64, ppc, ppc64, ia64, parisc, parisc64, s390, s390x, sparc, sparc64, mips, mips64, alpha, arm, arm-be, arm64, arm64-be, sh, sh64, m86k のいずれかの値を取り、特定アーキテクチャをチェックする。アーキテクチャは、 uname(2) が返す情報を元に決まる。このため、 personality(2) に従う。 なお、同じユニットファイルの Personality= 設定はこの判定に影響しないことに注意。特別なアーキテクチャ名 native は、システムマネージャ自身がコンパイルされた対象アーキテクチャにマップされる。感嘆符を前につけると判定は逆にできる。
ConditionVirtualization= は、システムが仮想化環境で実行しているかをチェックするのに使う。特定の実装であるかも判定できる。ブール値のときは、なんらかの仮想化環境で実行しているかどうかを判定する。 vm と container のときは、仮想化ソリューションの一般的タイプを判定する。qemu, kvm, vmware, microsoft, oracle, xen, bochs, chroot, uml, openvz, lxc, lxc-libvirt, systemd-nspawn のときは、特定の実装であるかを判定する。複数の仮想化技術がネストしている場合、最も内側のものだけが考慮される。感嘆符を前につけると判定は逆にできる。
ConditionHost= は、ホストのホスト名あるいはマシンID を判定する。ホスト名文字列（オプションで、シェルスタイルのグロブも可能）の場合は、ローカルに設定され、 gethostname(2) で返るホスト名との比較がされる。マシンID（machine-id(5) を参照）は文字列形式である。感嘆符を前につけると判定は逆にできる。
ConditionKernelCommandLine= は、特定のカーネルコマンドラインオプションがセットされているか（感嘆符でプレフィックスしたときは、セットされていないか）をチェックするのに使う。引数は、単独の単語であるか、代入（つまり、２単語で、 "="）でなくてはいけない。前者の場合、カーネルコマンドラインで、その単語がそのまま、あるいは、代入の左辺に現れるのを探す。後者の場合、代入の左辺と右辺がそのままマッチするのを探す。
ConditionSecurity= は、指定したセキュリティモジュールがシステムで有効化をチェックするのに使う。現在、認識される値は、 selinux, apparmor, ima そして smack。感嘆符を前につけると判定は逆にできる。
ConditionCapability= 指定したケーパビリティが、サービスマネージャの capability bounding set にあるかチェックするのに使う。（これはケーパビリティが実際に permitted あるいは effective set にあって使用可能かはチェックしない。詳しくは、capabilities(7) を参照。）"CAP_MKNOD" のようなケーパビリティ名を与える。感嘆符を前につけると判定は逆にできる。
ConditionACPower= は、ユニットがアクティベートされたとき、システムが AC 電源を持っているか、電池で給電されているかをチェックするのに使う。ブール値の引数を取る。true なら、システムで少なくとも一つの AC コネクターが電源につながっているとき、あるいはAC コネクターが存在しない時、条件は真となる。逆に、false ならば、１つ以上の AC コネクターが存在し、かつ、すべての AC コネクターが電源につながっていない時、条件は真となる。
ConditionPathExists= は、ユニットが開始する前に、あるファイルが存在するかチェックする。指定された絶対パス名が存在しない場合、条件は偽となる。ConditionPathExists= に与えられた絶対パス名が感嘆符 ("!") でプレフィックスされている場合、条件は逆に評価され、ユニットはそのパスが存在しない場合に限り開始する。
ConditionPathExistsGlob= は、 ConditionPathExists= に似ている。しかし、指定されたグロブパターンにマッチする少なくても１つのファイルあるいはディレクトリの存在をチェックする。
ConditionPathIsDirectory= は、 ConditionPathExists= に似ている。しかし、指定されたパスが存在し、ディレクトリであるかをチェックする。
ConditionPathIsSymbolicLink= は、 ConditionPathExists= に似ている。しかし、指定されたパスが存在し、シンボリックリンクであるかをチェックする。
ConditionPathIsMountPoint= は、 ConditionPathExists= に似ている。しかし、指定されたパスが存在し、マウントポイントであるかをチェックする。
ConditionPathIsReadWrite= は、 ConditionPathExists= に似ている。しかし、そのパスが存在するファイルシステムが読み書き可能かをチェックする。（リードオンリーでマウントされていない）
ConditionDirectoryNotEmpty= は、 ConditionPathExists= に似ている。しかし、指定されたパスが存在し、空でないディレクトリであるかをチェックする。
ConditionFileNotEmpty= は、 ConditionPathExists= に似ている。しかし、指定されたパスが存在し、ゼロでないファイル長を持つ通常ファイルであるかをチェックする。
ConditionFileIsExecutable= は、 ConditionPathExists= に似ている。しかし、指定されたパスが存在し、通常ファイルで、かつ実行可能であるかをチェックする。
最後に、ConditionNull= は、定数の条件チェックをユニットに加えることに使う。ブール引数を取る。false の場合、条件は常に偽となる。そうでない場合、常に真となる。
複数の条件が指定された場合、ユニットは、すべてが真であるとき（つまり、論理 AND が取られる）に実行される。条件チェックはパイプシンボル (|) でプレフィックスすることができ、その場合、条件は、triggering 条件となる。あるユニットに少なくても１つの triggering 条件が定義されている場合、ユニットは少なくても１つの triggering 条件が真で、かつ、すべての triggering でない条件が真の時に実行される。引数をパイプシンボルと感嘆符でプレフィックスすると、まずパイプが評価され、次に感嘆符が評価される。ConditionPathIsSymbolicLink= 以外は、パスチェックはシンボリックリンクをたどる。これらのいずれかのオプションに空文字列を指定すると、条件のリストは完全にリセットされ、すべての以前の条件設定（種類にかかわらず）は効果を持たなくなる。
SourcePath=¶
このユニットが生成される元となった設定ファイルのパス。これは主に、外部の設定ファイル形式からネイティブなユニットファイルに変換する生成ツールの実装に使う。このため、普通のユニットでこの機能を使うべきではない。
ユニットファイルは [Install] セクションを持つことがある。それは、ユニットのインストール情報を持つ。このセクションは、実行時に systemd(1) により解釈されることはない。それは、systemctl(1) ツールの enable と disable コマンドがユニットをインストールするときにだけ使われる。
Alias=¶
空白で区切られた、このユニットがその名前でインストールされるべき、追加の別名のリスト。ここにリストされる名前は、ユニットファイル名と同じサフィックス（つまりタイプ）を持たなくてはいけない。このオプションは１回以上指定することができ、すべての指定された名前が使われる。インストール時に、systemctl enable はこれらの名前から元のユニットファイル名に対してシンボリックリンクを作成する。
WantedBy=, RequiredBy=¶
このオプションは、１回以上指定することができる。または、空白で区切られたユニット名のリストを使うこともできる。このユニットが systemctl enable でインストールされるとき、ここでリストされたユニットに対応する、 .wants/ あるいは .requires/ ディレクトリに、シンボリックリンクが作成される。これは、リストされたユニットから現在のユニットに、 Wants= あるいは Requires= タイプの依存関係が追加されるのと同じ効果を持つ。主な結果は、リストされたユニットが開始するとき、現在のユニットが開始されることである。詳しくは、 [Unit] セクションの Wants= と Requires= の説明を参照。
サービス bar.service に WantedBy=foo.service と書くのは、同じファイルに、 Alias=foo.service.wants/bar.service と書くのとほぼ同じである。テンプレートユニットの場合、 systemctl enable はインスタンス名を指定して実行されなくてはいけない。そのインスタンスが、リストされたユニットの .wants/ あるいは .requires/ リストに追加される。例えば、サービス getty@.service に WantedBy=getty.target があると、 systemctl enable getty@tty2.service は、 getty@.service へのリンク getty.target.wants/getty@tty2.service を作成する。
Also=¶
このユニットがインストールあるいはアンインストールされるときに、インストールあるいはアンインストールされる追加のユニット。このオプションがあるユニットを、ユーザーがインストールあるいはアンインストールするとき、systemctl enable と systemctl disable は、自動的にここでリストされるユニットもインストールあるいはアンインストールする。
このオプションは、１回以上指定することができる。または、空白で区切られたユニット名のリストを使うこともできる
以下の specifier は、インストールセクションで解釈される。%n, %N, %p, %i, %U, %u, %m, %H, %b, %v。それぞれの意味は、次のセクションを参照。
Specifier は、実行時のあるいはユニットのパラメータを参照し、ユニットファイルがロードされた時に置換される。これにより、一般的なユニットファイルを書くことができる。Specifier は、多くの設定で使われる。以下の specifier が理解される。
Table 3. ユニットファイルで指定できる specifier
systemd(1), systemctl(8), systemd.special(7), systemd.service(5), systemd.socket(5), systemd.device(5), systemd.mount(5), systemd.automount(5), systemd.swap(5), systemd.target(5), systemd.path(5), systemd.timer(5), systemd.snapshot(5), systemd.scope(5), systemd.slice(5), systemd.time(7), capabilities(7), systemd.directives(7), uname(1)