86

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 ?

Vikas Tiwari
  • 983
  • 1
  • 6
  • 6

9 Answers9

74

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.

Pablo A
  • 177
  • 1
  • 9
Sven
  • 98,649
  • 14
  • 180
  • 226
  • 3
    Thanks @Sven. Where are these configurations defined ? – Vikas Tiwari 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 ? – Vikas Tiwari Apr 20 '17 at 10:03
  • 6
    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
  • @Sven Where is the service file? – User Mar 25 '18 at 17:36
  • `StartLimitIntervalSec=` was added as part of systemd v230. In systemd v229 and below, you can only use `StartLimitInterval=`. To check your systemd version on CentOS, run `rpm -q systemd` – Pradip Shenolkar Mar 30 '19 at 09:56
  • 1
    @user service files are in /lib/systemd/system – Mashrur Nov 07 '19 at 06:04
33

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

Peter
  • 2,756
  • 1
  • 20
  • 26
  • 1
    **start it ignoring this _absurd_ limit nonsense** that alone is worth its weight in silver (not gold: silver is my favourite precious metal)! And thank you for the command. This combined with fixing permissions (ownership in particular) - new install - solved my problem. – Pryftan May 23 '23 at 16:13
2

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.

JonathanDavidArndt
  • 1,424
  • 3
  • 20
  • 29
MickG
  • 29
  • 1
0

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

User=my_user

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.

kklepper
  • 109
  • 1
0

Just like Peter's answer above,

since this is the one that comes up when searching...

If you merely need to refresh the config, consider reload instead of restart. E.g.:

service nginx reload
ᴍᴇʜᴏᴠ
  • 577
  • 1
  • 6
  • 20
0

Consider also RestartSec - More info in man systemd.service:

Configures the time to sleep before restarting a service (as configured with Restart=). Takes a unit-less value in seconds, or a time span value such as "5min 20s". Defaults to 100ms.

In my case, a service encountered and error and stopped, but the default RestartSec is 100ms so it was starting again too quickly for the condition to clear up on its own, so RestartSec=60 (a value of 60 seconds) helped.

chouse
  • 1
0

I got same error after I cloned debian 11 to another vm, this vm won't start ssh. dpkg-reconfigure openssh-server did not work, editing sshd.service also did not work. A quick & dirty 'apt purge openssh-server && apt install openssh-server' did the trick.

grepmaster
  • 143
  • 2
  • 4
  • 14
0

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.

mivk
  • 4,004
  • 3
  • 37
  • 32
-1

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..

/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
deploycat
  • 35
  • 3