How to make systemd timer run exactly every 10 minutes, with a task that lasts slightly longer than that?

Question

I have a rather annoying issue with systemd timers and drifting start time. I had an old cron.d script (which executed faithfully once every 10 minutes) that I'm trying to modernize. The problem is that the service it starts runs a while longer than 10 minutes. With cron this was not an issue, I simply had two instances running for a while, but systemd does not work the same.

The timer is as follows:

[Timer]
OnCalendar=*:0/10:0
Persistent=false
AccuracySec=1s

and from what I understand, this is supposed to run at exactly 08:00:00, 08:10:00, 08:20:00, and so on and so forth. But the associated service it starts runs slightly longer than 10 minutes, and this causes the timer to gradually drift by about 10 seconds per run. Meaning the start times are 08:00:00, 08:10:10, 08:20:20 and so on. Is there any way to force the timer to do exactly as I want?

I've also attempted to make the service to run in the background, unmonitored by systemd, but I have not had much success with this. Tried things like ExecStart=/bin/sh -c "/run/my/cmd -options &" and with nohup and putting the whole command in a separate shell script to no avail. The cmd is not started or dies immediately.

So how can I make my systemd timer behave like the old cron script? My only remaining idea/workaround is to make two timers, set at 20 minute intervals, but that sounds like a really dumb idea..

Answer 1

It would appear that this type of behavior is really not directly supported by systemd, which sort of makes sense due to the way it tracks every service it runs. I ended up having to create two identical services which run every 20 minutes instead of every 10 minutes.

The relevant timer sections are as follows:

myservice-even.timer

[Timer]
OnCalendar=*:0/20:0
Persistent=false
AccuracySec=1s

and

myservice-odd.timer

[Timer]
OnCalendar=*:10/20:0
Persistent=false
AccuracySec=1s

In addition I included RuntimeMaxSec=900 to both services, so that even if they misbehave, next round starts at the correct time.

Answer 2

If you want to start a process asynchronously (and independently of any other instance), you can use systemd-run. systemd-run creates a transient service or scope unit. By default, it automatically generates a unique name for the unit.

In other words, a systemd service S can use systemd-run to start a process P. systemd-run will not wait for P to finish (unless you use the --wait option). Process P will not be part of service S. And process P will not be killed when service S stops.

If you like, you should be able to use options like --property RuntimeMaxSec=900 with systemd-run. (Exactly which properties you can set with systemd-run varies a bit. I think older versions of systemd did not allow setting as many of the properties on the transient unit).

If you needed to add more complex controls than provided by cron, or even more complex controls than are possible with transient service units, you might need to find another task scheduler that has the features you need. Or write a service of your own which spawns child processes and watches their status :-). (You could still use systemd timers to message such a service, but I don't think it would look very clean. If you want it to be understandable, I think it would be better for the service to implement the timer itself.)