web-dev-qa-db-ja.com

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

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

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

さらに、何をtoo quickly正確に言うと、一定期間の再起動回数の制限ですか？

linuxsystemd
29
Vikas Tiwari

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

レートは、StartLimitIntervalSec=およびStartLimitBurst=オプションを使用して構成され、Restart=オプションは、SystemDがサービスを再起動するタイミングを制御します。

詳細man systemd.unitおよびman systemd.service。

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

30
Sven

原因は異なりますが、いくつかの障害がこのエラーをスローするように見えることは注目に値します。

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

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

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

サービス開始要求があまりにも速く繰り返され、エラーの開始を拒否

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

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

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

2
MickG

このエラーで開始に失敗するサービスは指定しません。

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

Fail2banでは、解決策はそれを

fail2ban-client -x start

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

設定エラーが修正されたら、systemdを使用してサービスを再度停止または（再）開始できます。

0
mivk

私がこの同じ問題に使用した素早い方法の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
0
deploycat