Linux – Is it better to use the systemd service unit’s Restart & RestartSec, or use a systemd timer unit

cronlinuxsystemdtime

I have a couple of in-house automated scripts running at periodic intervals. One is every five minutes, the other is every minute. They don't really need to be ran on-the-dot; e.g. I don't care if they run at 12:00, 12:05, etc. or at 12:03, 12:08, etc., I just need a steady interval.

Currently, I have crontab running these scripts at the specified intervals. However, on the same machine I also have custom in-house systemd service unit files. I was curious if it would be better to move my scripts to systemd service unit & timer files, or just use systemd service unit files with Restart & RestartSec directives.

Let me know if I need to rephrase something or if I'm being unclear.

Specifically, the definition for systemd.service units translates Restart=always and RestartSec=300 to be synonymous as "always run every five minutes while ignoring the exit code of the previous run". However, there's also the systemd.timer unit that could be configured to do the same but probably with specific exit codes such as successful exit only.

I'm looking for pros and cons of both.

Thanks!

Best Answer

I recommend to use a process manager to do your job. Luckily you have the best process manager ever on board, systemd. In my eyes it is about semantics, even if both solutions are working for your case.

Use timer units for cron-like schedules you are talking about.
Use restart statements to specify a restart policy of a task that ends unexpected. That means you even can define a restart policy for your timer units, in case they failed. Keep in mind that restarting units quickly enter failed states, because they quickly reach a holdoff timeout, if you don't define a RestartSec greater than 1.

Related Solutions

How to set environment variable in systemd service

Times change and so do best practices.

The current best way to do this is to run systemctl edit myservice, which will create an override file for you or let you edit an existing one.

In normal installations this will create a directory /etc/systemd/system/myservice.service.d, and inside that directory create a file whose name ends in .conf (typically, override.conf), and in this file you can add to or override any part of the unit shipped by the distribution.

For instance, in a file /etc/systemd/system/myservice.service.d/myenv.conf:

[Service]
Environment="SECRET=pGNqduRFkB4K9C2vijOmUDa2kPtUhArN"
Environment="ANOTHER_SECRET=JP8YLOc2bsNlrGuD6LVTq7L36obpjzxd"

Also note that if the directory exists and is empty, your service will be disabled! If you don't intend to put something in the directory, ensure that it does not exist.

For reference, the old way was:

The recommended way to do this is to create a file /etc/sysconfig/myservice which contains your variables, and then load them with EnvironmentFile.

For complete details, see Fedora's documentation on how to write a systemd script.

Systemd timer not starting its service unit

Although timer units automatically gain a Before= dependency on the service they are supposed to activate, they apparently don't automatically have a Requires= dependency on it (which doesn't make any sense to me).

So I added the following line to the [Unit] section of the timer unit, and now it starts the service as intended :

Requires=letsencrypt-example_com.service

I also set an AccuracySec (of 10s) in the [Timer] section.

Best Answer

Related Solutions

How to set environment variable in systemd service

Systemd timer not starting its service unit

Related Topic