12

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.

Jeff Schaller
  • 66,199
  • 35
  • 114
  • 250
somethingSomething
  • 5,721
  • 18
  • 58
  • 98

3 Answers3

13

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.

Mark Stosberg
  • 7,420
  • 1
  • 32
  • 42
  • 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. – Ferenc Wágner May 09 '19 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 Jun 26 '23 at 16:00
7

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

sizif
  • 121
  • 1
  • 4
  • Can you explain what `reset-failed` does? – annahri Oct 08 '21 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 Oct 10 '21 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.

AdminBee
  • 21,637
  • 21
  • 47
  • 71
kklepper
  • 101
  • 1