解決策 1:
デフォルトの制限は、10 秒間に 5 回の再起動を許可することです。 Restart= が原因でサービスがそのしきい値を超えた場合 config オプションをサービス定義に追加すると、それ以上の再起動は試行されません。
レートは StartLimitIntervalSec= で構成されます そして StartLimitBurst= オプションと Restart= オプションは、SystemD がいつサービスを再起動しようとするかを制御します。
詳細は man systemd.unit で および man systemd.service .
次に systemctl daemon-reload を使用します ユニット構成をリロードします。
解決策 2:
まったく同じ質問ではありませんが、これは検索すると出てくる質問なので...
このばかげた制限のナンセンスを無視して開始したいだけの場合（たとえば、Debianでは、サービスが失敗してループして制限に達する運命にあり、開始時にログを非常に激しくスパムするように設定される前に、apt自動開始サービスの必然的な結果です）原因を簡単に読み取ることさえできないエラーを制限します):
https://bugzilla.redhat.com/show_bug.cgi?id=1016548 を参照してください。Michal Schmidt によると、man systemd.service で見つけることができます そして、失敗したステータスをリセットすることを提案します:
systemctl reset-failed <service name>
これで、サービスが開始される可能性があります。または、少なくともログに記録されるべきではない実際の最新の原因。 journalctl -x で見られる
解決策 3:
いくつかの障害がこのエラーをスローするように見えますが、原因は異なることに注意してください。
デフォルトのバンタイムをコメントアウトし、代わりの inline**bantime = 7200 #3600** を挿入しました
新しいセクション [sasl] も追加しました 、これには、私がフォローしていた記事で指定されたものから変更されたフィルター名が含まれていました.
それらのいずれかでエラーが発生する代わりに、fail2ban は再起動を拒否し、
<ブロック引用>サービス開始リクエストの繰り返しが速すぎて、starterror を拒否しました
[sasl] セクションをコメントアウトしたときのみ、無効な bantime を参照するエラーが表示されました。このエラーから、インライン コメントを処理できないことがわかりました。
それを修正して新しい [sasl] セクションのコメントを外したところ、フィルターが見つからないというエラーが表示されました。正しい名前のフィルターを置き換えると、予想どおりに fail2ban がリロードされました。
そのため、変更を行ってこのエラーが発生した場合は、症状を修正する前に、変更を削除しても同じエラーが発生することを確認してください。