私が文書で知っている限りシステム、電子が依存ユニットファイルに配置され、その逆の場合を除いてWants=同じWantedBy=機能を実行します。 （次にディレクトリを WantedBy=作成し、シンボリックリンクで埋めます。）unit.type.wants
~からDigitalOcean：Systemdユニットとユニットファイルの理解:
このディレクティブを使用すると、このセクションのディレクティブと
WantedBy=同様の方法で依存関係を指定できます。違いは、このコマンドがセカンダリに含まれており、リストされているプライマリデバイスが比較的クリーンな状態に保たれることです。Wants=[Unit]
これは本当にユニットファイルを「きれいに」保つためのものですか？これら2つのディレクティブを使用する最良の方法は何ですか？つまり、サービスアルファがサービスベータを「望む」場合は、いつWants=beta.serviceinを使用し、alpha.serviceいつWantedBy=alpha.service使用する必要がありますかbeta.service？
ベストアンサー1
機能的に
WantsUnit部分的に位置し、WantedByに位置しますInstall。
initプロセスはその部分をまったくsystemd処理/使用しません。Install代わりにシンボリックリンクを作成する必要がありますmulti-user.target.wants。通常、これはsystemctlセクションを読むユーティリティによって行われますInstall。
つまり、WantedBy影響を受けます。systemctl enablesystemctl disable
論理的に
どのサービスが他のサービスを「認識」するか、「認識」するかを検討してください。たとえば、一般的な使い方は次のとおりですWantedBy。
[Install]
WantedBy=multi-user.target
または multi-user.target で次の操作を行います。
[Unit]
Wants=nginx.service
しかし、2番目の方法は意味がありません。論理的には、nginx.serviceはシステム定義のmulti-user.targetについて知っていますが、その逆ではありません。
したがって、あなたの例では、アルファの作成者がベータを知っている場合、アルファWantsはベータです。ベータ作者がアルファを知っているなら、ベータはWantedByアルファです。
決定に役立つように、他のサービス（パッケージマネージャなど）なしでインストールできるサービスを検討してください。
構成ディレクトリ
ボックスにある別のツールとして、構成ディレクトリ/etc/systemd/system/myservice.service.d/extension.confを使用してsystemdファイルを拡張することもできます。
これにより、元のサービスが他のサービスの知識として生成されなかった依存関係を追加できます。私はしばしばこれをマウントで使用します。たとえば、nginxやマウントはお互いを明示的に知る必要はありませんが、システム管理者としての依存関係を理解しています。だからnginx.service.d/mymount.conf私はWants=mnt-my.mount。