Service start request repeated too quickly, refusing to start limit
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.