サービス開始要求が速すぎるため、制限の開始を拒否しました

次のエラーを表示するsystemdサービスがあります service start request repeated too quickly, refusing to start

サービスは障害時に再起動するように構成されており、何度も再起動することを理解しています。しかし、いつ再起動を拒否するのですか？それを定義する制限または数はありますか？

さらに、too quickly正確に何を意味するのか、それは一定期間内の再起動回数の制限ですか？

デフォルトの制限は、10秒間に5回の再起動を許可することです。Restart=サービス定義の構成オプションが原因でサービスがそのしきい値を超えた場合、それ以上の再起動は試行されません。

SystemDがサービスの再起動を試行するタイミングStartLimitIntervalSec=とStartLimitBurst=オプションおよびRestart=オプションを制御して、レートを設定します。

詳細情報でman systemd.unitとman systemd.service。

次に、systemctl daemon-reloadユニット構成の再読み込みに使用します。

原因は異なりますが、一部の障害ではこのエラーがスローされるように見えることに注意してください。

デフォルトの禁止時間をコメントアウトし、代替のインラインを挿入しました **bantime = 7200 #3600**

また、新しいセクション[sasl]を追加しました。このセクションには、私がフォローしていた記事に記載されていたものから変更されたフィルター名が含まれています。

これらのいずれかでエラーを発生させる代わりに、fail2banは再起動を拒否し、

サービス開始リクエストの繰り返しが速すぎるため、エラーの開始を拒否しました

[sasl]セクションをコメントアウトした場合にのみ、無効な禁止期間に関するエラーが発生しました。このエラーから、インラインコメントに対応できないことがわかりました。

それを修正し、新しい[sasl]セクションのコメントを外したとき、フィルターが見つからないというエラーが表示されました。正しく名前が付けられたフィルターを置き換えると、fail2banが期待どおりにリロードされました。

したがって、変更を加えてこのエラーが発生した場合は、症状を修正する前に、変更を削除しても同じエラーが発生することを確認してください。

この同じ問題に使用した簡単で汚い方法の1つは、スリープ状態のbashラッパースクリプトを作成して、サービスがそれほど速く起動しないようにすることです。すぐに再起動する必要がないので、私のために機能します。

/root/sleep_and_start_autossh.sh

    /bin/bash -e
    sleep 200
    /usr/bin/autossh args...

/etc/systemd/system/autossh.service

    StartLimitIntervalSec=120 # this didn't seem to do much for me.
    #ExecStart=/usr/bin/autossh args ...
    ExecStart=/root/sleep_and_start_autossh.sh

このエラーで起動に失敗するサービスを指定しません。

でこの問題が発生しfail2banましたが、MickGの回答のように、実際にはfail2ban構成にエラーがあり、systemdサービスの構成とは何の関係もありませんでした。

fail2banでは、解決策は次のように開始することです

fail2ban-client -x start

詳細なエラーメッセージが表示されます。何らかの理由でsystemctl start fail2ban、実際のエラーを使用すると失われ、どのログにも見つかりません。

構成エラーが修正されると、systemdを使用してサービスを再び停止または（再）開始できます。