1.）multi-user.targetデフォルトでは、クラシックSysVinitランレベル3に最も似ていますsystemd。systemdシステムが起動すると、systemdシステム状態を - で指定された状態と一致させる試みが行われます。これは通常またはのエイリアスですdefault.target。graphical.targetmulti-user.target

multi-user.target通常、すべてのネットワークサービスが開始され、システムがログインを許可するがローカルGUIが起動しないシステム状態が定義されます。これは、リモートサーバールームのラックマウント型ヘッドレスシステムである可能性があるサーバーシステムの一般的な基本システム状態です。

graphical.targetはい、別の可能な別名ですdefault.target。通常、これは次の親セットとして定義されますmulti-user.target。これには、multi-user.target実行されたすべての操作とローカルGUIログインの有効化が含まれます。クラシックSysVinitのランレベル5に少し似ています。

このサービスの行は、SysVinitシステムで「このサービスは実行レベル3、4、5で開始する必要があります」を指定するのとWantedBy=multi-user.target本質的に同じです。systemdローカルサービスGUIがアクティブです。

ただし、WantedBy有効/無効状態とは別です。つまり、別の意味では「事前設定」です。自動起動が発生する可能性がある条件を決定しますが、サービスが初めて有効になっている場合にのみ適用されます。

2.) この行を省略し、アクティブなWantedBy=multi-user.target他のサービスにサービス定義にRequires=your.service含まれていない場合、Wants=your.serviceサービスは自動的に開始されません。

systemd依存関係に対して機能し、起動時にサービスに何もない場合、サービスがアクティブになっても起動しませんRequires。Wants

もちろん、起動時に開始したいサービスのdefault.target追加、削除、Requiresまたは行を編集できますWants。ただし、これにより、新しいサービスファイルをシステムに配置してデフォルトで動作させることができます（これはソフトウェアが非常に簡単になります）systemd。WantedByRequiredByWantsRequires

3.) 場合いいえ起動時にサービスが自動的に開始されるようにするにはまたはサービスは、明確に定義された依存関係チェーンの一部です。

たとえば、サーバーアプリケーションAをリファクタリングし、何らかの理由でユーザーが必要でない場合にインストールしないことを選択できるように、一部のオプション機能を別々のサービスBに分割することを決定できます。その後、サービスBを個別に作成し、サービスAが起動したときにサービスBが自動的に開始されるようにservice-B.rpm定義できますB.service。ただし、実際にインストールされている場合にのみ可能ですWantedBy=A.service。systemdservice-B.rpm

あるいは、Wants単にWantedBy他のサービスまたはターゲットが起動したときにシステムが1つのサービスを開始する必要があることを意味しますが、開始/終了順序についてはまったく指定しません。サービスAの起動時にサービスBがすでに実行されている必要がある場合は、ファイルに追加してBefore=A.service開始B.service順序の依存関係を明示的に指定する必要があります。

4.) いつでもする起動時にサービスが自動的に開始され、他の依存関係が定義されていないことを願っています。

削除するとWantedBy=multi-user.target（systemctl enable your-example-hereうるさい）何もできなくなります。

グラフィックターゲット

ソースから純粋なsystemdをインストールした場合、起動される「デフォルトのターゲット」はですgraphical.target。

開始graphical.target開始multi-user.targetおよびグラフィカル・ユーザー・インターフェースを提供するために必要なすべての単位。これらの追加の複雑さは、従来の「実行レベル」をシミュレートするために用意されています。

あなた本物「ランレベル」偽装は無視またはマスクする必要があります。とにかく正常に動作しません。すみません！歴史的に「グラフィック」と「マルチユーザー」を強調した理由は、グラフィックソフトウェアが1）システムの他の部分ほど強力で成熟せず、2）多くのリソースが必要であるためです。

通常、特定の単位は数個しかありませんgraphical.target。 GUI自体にはサービスがあります。たとえば、gdm.targetいくつかのサポートサービスがあります。最大ここのGUIもこれを使用します。

編集：インターネット検索ではgraphical.targetGUIがインストールされていませんが、「デフォルトのターゲット」が残っている場合はsystemdが警告を記録できることを示唆しています。 "display-manager.serviceデバイスの依存関係タスクを追加できませんでした。無視：デバイスdisplay-manager.serviceの読み込みに失敗しました。そのファイルまたはディレクトリはありません。"ログに不要な警告が表示されないようにします。したがって、GUIがインストールされていない場合はを使用してくださいsystemctl set-default multi-user。オペレーティングシステムのインストールシステムがこの問題を解決した可能性があります。それ以外に、私はこの問題について無関心を維持することを強く支持します:-)。

システム初期化対象

特定のサービスやその他のタイプのユニットは、「初期開始に参加」します。これはBefore=sysinit.target直接的または間接的な開始として定義されます。ほとんどのサービスは開始のみですAfter=sysinit.target。サービスが設定されていない場合は自動的に開始されますDefaultDependencies=no。

マルチユーザーターゲット

ほとんどのサンプルサービスは上記のカテゴリに属していないため、そのカテゴリに追加しますmulti-user.target。これには、プロトタイプシステムサービスであるほとんどのネットワークサービス（Webサーバーなど）が含まれます。

動的にアクティブなサービス

見ることができるもう一つの可能​​性はサービスユニットです。いいえ起動時に自動的に起動します。したがって、必要ありませんWantedBy=multi-user.target。サービスは、他のものによってトリガーされるか、「アクティブ化」され得る。

一例は、dbus アクティベーションサービスです。 Dbus呼び出しがサービスに行われると、要求時にサービスを開始するようにDbusを構成できます。

ネットワークサービスの場合は、ソケットアクティベーションサービスを使用できます。すべての設定がシステムデバイスにあるため、詳細を見つけるのが簡単になる可能性があります。たとえば、またはsshd.socketを有効にするためにしばしばまたはをssh.socket使用できます。それでも、起動時にsshdサービスを開始する方が一般的だと思います。[email protected][email protected]

---

いつものように、上記の内容は単純化され、不要に見える詳細は省略されています。

これはmulti-user.target意味論的な名前、つまり意味に関連付けられています。反例を通してこの概念を説明します。どのクレームを使用するかについての私の決定は、multi-user.target状況によって異なります。

systemdを作成したい場合ユーザー単位代わりに構成システム装置構成では、素直にsystemdシステムデバイスの規則に従い、multi-user.target^1を使用できます。

反例の説明

文書を考える/home/jonathan/.config/systemd/user/coolstuff.service

このユーザーはユーザーだけが使用できるので、jonathan私のターゲットを「multi-user.target」と呼ぶことは意味がありません。

[Unit]
Description=Does some cool stuff.

[Service]
ExecStart=/bin/bash -c '/usr/bin/echo "Cool stuff" >> %h/coolstuff.txt'

[Install]
WantedBy=user.target

私がどのように使用しているか見てくださいWantedBy=ユーザー。対象。これは、このコンテキストの範囲が私のユーザーアカウントであるため、私自身のセマンティクスを使用することを選択しました。つまり、複数のユーザーがこのシステムの影響を受けません。ただし、システムレベルでは、並列起動順序のために標準化された規則に従う方が合理的です。起動中、多くのプロセスが複数の目標に焦点を当てています。これはmulti-user.target、意味論的には、「システムとのユーザーエンゲージメント/相互作用の読み取り」（言及されたWindowsシステムtelcoMなし）というアイデアに関連付けられているため、ほとんどのシステムデバイスファイルにとって安全な選択です。

脚注

1. この場合、意味がなくてもまだ機能します。