私はsystemdfw.serviceユニットファイルを持っており、これは次の要件ですnetworking.service。
# systemctl show networking -p Requires
Requires=system.slice fw.service
#
networking.serviceそのactive状態で実行すると、systemctl stop fw数秒後にその状態が維持されsystemctl start fwます。ただし、状態で実行すると再起動します。networking.serviceinactive (dead)networking.serviceactivesystemctl restart fwnetworking.service
これが予想される動作ですか？私の考えsystemctl restartには基本的にsystemctl stopギリギリな瞬間systemctl startなのでsystemctl start発売しなければならないと思いますnetworking.service。
ベストアンサー1
restartstop+ と似ていますstartが、同じではありません。ジョブはサービスマネージャrestart内で異なる方法で処理されますsystemd。systemctlインターフェースの単純な利便性ではありません。 [*]
この特定の動作で判断すると、現在のバージョンのman systemd.unit.（少なくとも私のインストールではsystemd-239）です。
行動がstop文書化されました。そして動作はstart文書とも一致します。明示的に文書化されていないのは、restart必要な単位への伝播ですfw.service。しかし、他の種類の依存関係でこれについてのヒントを見ました。
部分=
と同様に依存関係を構成します
Requires=が、デバイスを停止して再起動することに制限されます。 systemdがここにリストされているデバイスを停止または再起動すると、ジョブはそのデバイスに伝播されます。これは一方向の依存関係です。このデバイスを変更しても、リストされているデバイスには影響しません。
ヒントは、PartOf=がの制限されたサブセットである場合、Requires=すべての操作が実行されることです。したがって、これには伝播再始動が含まれる。Requires=PartOf=
networking.service最初のステップで停止したくない場合に置き換えることができRequires=fw.serviceますWants=fw.service。ただし、Requires=ファイアウォールルールが有効になっていない場合は、ネットワークが絶対にアクティブにならないようにするために意図的に使用されているようです。
再起動が順次行われるようにnetworking.service設定することで、アクティベーションなしでアクティブにならないようにすることもできます。実際にそのようなことが起こるかどうかは確認できませんでした。 （それがあなたが望むものなら、この答えではなく他の機関を検証することをお勧めします：-）。fw.serviceAfter=fw.service
本当に欲しいなら、すでに設定しておくこともできそうWants=networking.serviceです。これは、これらの依存関係が特定の順序を意味しないために可能です。私の考えでは、システムにクラッシュがある場合にのみ「依存関係循環」の問題があるようです。fw.servicenetworking.serviceRequires=fw.service注文する依存関係 -After=とBefore=設定。
[*]systemd-logindたとえば再起動できるように設計、systemd再起動後も特定の重要なファイルを開いたままにします。ただし、ログインするだけでstop開いているファイルが失われます。 （私が知っている限り、systemd-logindを再起動すると、XorgまたはWaylandのすべての現在のバージョンはまだ中断されますが、systemdコードがアイデアを異なる方法で処理していることがわかりますrestart：-P）。