Service start request repeated too quickly, refusing to start limit

I have a systemd service that displays the following error service start request repeated too quickly, refusing to start

I understand that the service is configured to restart on failure and it is restarting again and again. But when exactly does it refuse to restart ? Is there a limit or number that defines it ?

Moreover, what does too quickly exactly mean, is it a limit of number of restarts in a given period of time ?

Solution 1:

The default limit is to allow 5 restarts in a 10sec period. If a service goes over that threshold due to the Restart= config option in the service definition, it will not attempt to restart any further.

The rates are configured with the StartLimitIntervalSec= and StartLimitBurst= options and the Restart= option controls when SystemD tries to restart a service.

More info in man systemd.unit and man systemd.service.

Then use systemctl daemon-reload to reload unit configuration.

Solution 2:

Not exactly the same question, but since this is the one that comes up when searching...

If you want to just start it ignoring this absurd limit nonsense (for example on Debian where it's the inevitable result of apt auto starting services before they are configured dooming them to fail and loop and hit the limit, spamming the log so hard with the start limit errors you can't even easily read the cause):

See https://bugzilla.redhat.com/show_bug.cgi?id=1016548 where Michal Schmidt says you can find it in man systemd.service and suggests to reset the failed status:

systemctl reset-failed <service name>

So now your service might start. Or at least the actual up to date cause of why it won't should be in the log, eg. seen with journalctl -x

Solution 3:

It is worth noting that some faults seem to throw this error, whereas the cause is different.

I commented out the default bantime and inserted an alternative inline **bantime = 7200 #3600**

I also added a new section [sasl], which included a filter name which had changed from the one given in the article I was following.

Instead of erroring at either of those, fail2ban refused to restart, giving the

service start request repeated too quickly, refusing to start error

Only when I commented out the [sasl] section, did I get an error which referred to an invalid bantime, from which I gathered that it cannot cope with inline comments.

When I fixed that and uncommented out the new [sasl] section, I got an error that the filter was not found. Substituting for the correctly named filter resulted in fail2ban reloading as expected.

So if you make changes and get this error, ensure you remove the changes and still get the same error before trying to fix a symptom.

Solution 4:

You don't specify which service fails to start with this error.

I had this problem with fail2ban, and as in the answer of MickG, the error was actually in my fail2ban configuration, and had nothing to do with the systemd service configuration.

With fail2ban, the solution is to start it with

fail2ban-client -x start

which will display a detailed error message. For some reason, when using systemctl start fail2ban the real error gets lost and cannot be found in any logs.

Once the configuration error is corrected, the service can again be stopped or (re)started with systemd.