from Hacker News

Working with Systemd Timers

by skwee357 on 3/10/25, 9:04 PM with 78 comments

• by tombert on 3/14/25, 2:13 AM

  I know everyone hates on systemd, but I've generally been happy with it, in no small part because I find the timers to be pretty sensible.

  They are, in all ways that I care about, simply better than cron, and especially in NixOS they're really easy to set up.

• by timrichard on 3/14/25, 2:16 AM

  When I started using systemd timers, I really liked the systemd-analyze calendar facility, to calculate n trigger times for a given calendar expression.

  For example, show the next five trigger times for the end of the last day when the month has 31 days :

  systemd-analyze calendar --iterations=5 '*-*-31 23:59:59'

• by notepad0x90 on 3/14/25, 3:16 AM

  There is one huge advantage of cron that is usually missed with such comparisons. cron is dead-easy to create and maintain. Systemd timers make sense in certain situations, but in 90%+ of my use cases so far, the added complexity really adds up the amount of time I'm administering my systems. I've been in a situation where I needed to troubleshoot why a systemd timer wasn't triggering, and I didn't like that experience at all. To me, it is something I would use if I actually needed it, it isn't a 1-to-1 replacement for cron.

• by merpkz on 3/14/25, 7:25 AM

  Minor nitpick - shouldn't you first define the service and only then a timer for it? Otherwise since you enabled timer and are still trying to figure out how to write service, systemd won't have anything to run when timer triggers. Maybe I am wrong, but that just feels like logical order. Anyways, after years on hating on systemd I also started to embrace it and porting my cron jobs to systemd timers and I must admit it's really nice, the overall overview with list-timers, next execution timestamp, total execution time, ordering of services so one can run after another is completed and of course the logging in journal so I can filter output and keep track of everything it's just wonderful experience.

  EDIT: yea, the email reporting is certainly missing, but it was hard to control it since whole STDOUT was shipped, which is not what I wanted most of the time anyways. It would be good to come up with some way to still have small overview emails sent about important jobs done, maybe a dependency service which starts when important job finished and just sends an email about that

• by kinglawrence on 3/14/25, 3:59 AM

  Really liked this read. Is anyone able to explain how the backup.timer runs the backup.service? It wasn't obvious to me where the trigger was defined. I guess it's just inherent to what that unit type does, and the fact that both units are named backup? What is the name for that "package" of units that make up the whole backup program?

• by MantisShrimp90 on 3/14/25, 1:39 AM

  It took a minute to setup, but using a combination of rsync and timers to backup system files has done wonders to decrease my anxiety around upgrades on arch

• by akeck on 3/14/25, 4:19 AM

  I used systemd user timers, a shell script, and an HDHomerun to make a simple VCR.

• by bhaney on 3/14/25, 2:52 AM

  I like systemd's timers when they're appropriate, but I really think the author's use case here is better suited to cron. The "issues" he listed for cron aren't very good either.

  > If you want to execute pre/post commands you have to do it inside the script itself

  So?

  > There are no built-in logs

  Every cron implementation I can remember using logs each run to syslog and emails me the output of the run by default

  > There is no built-in status monitoring

  I can't think of any built-in status monitoring that systemd has for timers that's materially different from cron's logging/emailing

  > If the system is down when the cron needs to run, the cron will be missed

  Some cron implementations support this and some don't. Most modern ones that I'm aware of do.

  Much more significantly, the amount of setup involved in a systemd timer is way higher than putting a line in a crontab, especially for the author's case of just running a backup script.

  Cron only involves running `crontab -e` and adding the line "@daily /path/to/script.sh" (which also handles the author's issue of cron "skipping" runs if the system was powered off, assuming the cron implementation uses something modern like anacron)

  Systemd involves writing a 7 line timer unit file, an additional 5 line service file, running a daemon-reload, then enabling the timer. It turns what's usually a 10 second mindless task into a much more involved procedure. That can be worth it if there are material benefits from it, but I'm not really seeing them here.

• by rs_rs_rs_rs_rs on 3/14/25, 5:48 AM

  I use them all the time, my only wish is they get rid of the .service file and make it possible to define the service inside the .timer file.

• by dmd on 3/14/25, 4:41 PM

  I would love to see something like https://github.com/isd-project/isd but for systemd timers.

• by burnJS on 3/14/25, 2:59 AM

  This is cool and after learning of this I'm tempted to convert my crons. I currently use systemd for running a redis queue and it's worked great for years.