Server Fault is a question and answer site for system and network administrators. It only takes a minute to sign up.
Sign up to join this community
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.
StartLimit... options might not be in there and just use the default (5 restarts in 10 sec).
/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.
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.
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.
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
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.
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.
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
StartLimitIntervalSec to avoid the throttling, or set it to 0 to disable. Read the systemd documentation.
Sep 22, 2018 at 15:31