ファイアウォールサービスデバイスをデバッグしていますが、いくつかの問題があります。
これらの質問の 1 つは、exec または oneshot であるかどうか、そのデバイスに最適なサービスの種類です。私の検索では、2つの比較はほとんどありませんでした。それはおそらく、execがsystemd（v.249 IIRC）に新しく追加されたためです。
バックグラウンドで、このユニット（iptables.serviceと呼ばれる）は、ネットワークが起動する前にBashスクリプト（iptables.shと呼ばれる）を実行してファイアウォール（iptables.shと呼ばれる）を有効にして設定するように設計されています。つまり、ネットワーク事前ターゲティング前）、例えば、
ExecStart=/bin/bash -c '/home/locsh/iptables.sh'
種類=使い捨て「アクティブ」状態に切り替えられないため、後で再起動または再アクティブ化できるという利点があります。例えば、タイマー装置を介して。説明はないが、ほとんどの例では、２つのタイプのうちより一般的である。
タイプ=実行利点は、基本サービスの実行が完了するまで後続のデバイスの起動が遅れることです。ネットワークは正常に実行されるスクリプトに依存する必要があり、そうでなければダウン状態を維持する必要があるため、これはファイアウォールサービスデバイスに完全に適しているようです。例えば、何らかの理由で関連する.mountユニットがまだアクティブになっておらず、スクリプトを一時的に読み取れない場合。
再開=失敗した場合どちらの場合も、これは明白で慎重な追加に見えます。
最初の質問何らかの理由で、どちらかが良いかもしれないということです。
2番目の質問Type = execは、デバイスの順序依存性のために「Restart = on-failure」であるかどうかにかかわらず、一部の極端な場合に微妙な順序サイクルを導入できる後続のデバイスの起動を遅らせますか？
Before=network-pre.target
比較的開始プロセスの初期段階です。
ベストアンサー1
あなたが欲しいtype=oneshot。を使用すると、type=execファイアウォールを構成する前に別のサービスを開始できます。systemd.serviceマニュアルページでは、次の点について説明しますexec。
...つまり、単純はfork（）が返された直後に追加の操作を続行しますが、execはサービスプロセスのfork（）とexecve（）の両方が成功するまで続きません。
のためoneshot：
oneshotは単に機能しますが、サービスマネージャは基本プロセスが終了した後にデバイスを考慮します。
つまり、Type=execサービスsystemdが「開始」された状態でここに行く、そしてのType=oneshot場合、systemdプロセスが成功するとサービスは「開始」されたと見なされます。十分。