15

I'm learning how to create services with systemd. I get this error:

.service: Start request repeated too quickly.

I can't start the service any more; it was working yesterday. What am I doing wrong?

(root@Kundrum)-(11:03:19)-(~)
$nano /lib/systemd/system/swatchWATCH.service
 1 [Unit]
 2 Description=Monitor Logfiles and send Mail reports
 3 After=syslog.target network.target
 4
 5 [Service]
 6 Type=simple
 7 ExecStart=/usr/bin/swatch --config-file=/home/kristjan/.swatchrc --input-record-separator="\n \n " --tail-file=/var/log/snort/alert --daemon
 8 Restart=on-failure
 9 StartLimitInterval=3
10 StartLimitBurst=100
11
12 [Install]
13 WantedBy=multi-user.target

StartLimitInterval and StartLimitBurst I added after trying to fix it.

My system is Debian 9.8 Stretch all updates.

3 Answers 3

15

First, if this is a custom service, it belongs in /etc/systemd/system. /lib/systemd is intended for package-provided files.

Second, the service is likely crashing and systemd is attempted to restart it repeatedly, so you need to figure out why it's crashing. Check the service logs with:

journalctl -e -u swatchWATCH

It's possible there will be some extra detail in the main journal:

journalctl -e

Finally, check to see it runs directly on the CLI ok:

/usr/bin/swatch --config-file=/home/kristjan/.swatchrc --input-record-separator="\n \n " --tail-file=/var/log/snort/alert --daemon

I see you are using a --daemon option. That's often a mistake with systemd. Systemd daemonizes for you. Try removing this option.

If all else fails, review what changed since yesterday when it was working.

2
  • Note that journalctl -u UNIT does not reliably display the dying messages of a unit, because there's no way to determine the origin cgroup of a message if the origin process is already dead. Commented May 9, 2019 at 12:25
  • grepping the journalctl -e fixed my problem. I found a line of code which was reliant on another service (MQTT broker) already being started. So, it appeared to work from the the commandline, but it would never start after a reboot.
    – KDM
    Commented Jun 26, 2023 at 16:00
9

The quick solution to "systemd[1]: SERVICE: Start request repeated too quickly" is

systemctl reset-failed SERVICE
systemctl start SERVICE
systemctl status SERVICE

Relevant quote from man systemctl:

reset-failed [PATTERN...]

... the start rate limit counter is reset to zero. Thus, if a unit's start limit (as configured with StartLimitIntervalSec=/StartLimitBurst=) is hit and the unit refuses to be started again, use this command to make it startable again."

2
  • Can you explain what reset-failed does?
    – annahri
    Commented Oct 8, 2021 at 22:34
  • 2
    @annahri man systemctl: "the start rate limit counter is reset to zero". "if a unit's start limit (as configured with StartLimitIntervalSec=/StartLimitBurst=) is hit and the unit refuses to be started again, use this command to make it startable again."
    – sizif
    Commented Oct 10, 2021 at 19:27
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.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .