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 ?


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.

  • 3
    Thanks @Sven. Where are these configurations defined ? Apr 20 '17 at 10:01
  • In the service file. The StartLimit... options might not be in there and just use the default (5 restarts in 10 sec).
    – Sven
    Apr 20 '17 at 10:02
  • Is the default value written in some other config file ? Apr 20 '17 at 10:03
  • 5
    The defaults can be configured, e.g. in /etc/systemd/system.conf with the DefaultStartLimitIntervalSec (and similar) options. However, these are often not set and the compiled-in defaults are used. See man systemd-system.
    – Sven
    Apr 20 '17 at 10:07
  • 1
    @user service files are in /lib/systemd/system
    – Mashrur
    Nov 7 '19 at 6:04

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


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.


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.


One quick and dirty way I just used for this same problem is I created a bash wrapper script that sleeps so that the service doesn't start as fast. Works for me as I don't need the immediate restarts..


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


    StartLimitIntervalSec=120 # this didn't seem to do much for me.
    #ExecStart=/usr/bin/autossh args ...
  • You need to lower StartLimitIntervalSec to avoid the throttling, or set it to 0 to disable. Read the systemd documentation. Sep 22 '18 at 15:31

In my case the error message was somewhat misleading. The reason for the failure resulted from a copy between machines. The line


in my service configuration file /etc/systemd/system/infinite_script.service was the culprit.

The new machine did not know of this user. Changing to User=root solved this problem.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.