Systemd is the new Cron

… and probably everything else too

I hate Cron

To start with, I must confess I hate Cron. And I think that it’s a common feeling.

But let’s explain my gripes: I’m not a sysadmin or anything close to that. I’ve been able to manage my linux distributions quite well for years, some servers too, but let’s face it: that’s a full time job to be good at sysadmin (or is it included in what people call fullstack?).

So I‘ve never managed to become confident about my cron jobs despite reading the man page every time I need to use it. Here are some open questions to me:

• how do I get a report (output is supposed to be emailed, but then you have a new problem: routing the mail)?
• how do I check that the job is actually running well (I mean, I don’t want to wait until midnight to fix my bugs)
• how do I know when my job will be triggered next time?
• what if my system was down at the time scheduled for a run?

And once again, yesterday, I needed to set up a scheduled job.

As nowadays all linux tools are being re-implemented into systemd (for better or worse), I had a look at systemd.timer.

Design & Use

What is great about systemd.timer is that it’s designed to run a service. That means you can first define a service, say learn.service, run it, make sure everything is ok: user it runs with, working dir, logging, anything, and then define a running schedule in learn.timer

Here is a my learn.timer file:

[Unit]
Description=Run learning everyday
[Timer]
OnCalendar=01:00
Persistent=yes
[Install]
WantedBy=timers.target

You have to enable the timer like any other service:

$systemctl enable learn.timer

And then you can check fox next runing time:

$ systemctl list-timers
NEXT LEFT LAST PASSED UNIT ACTIVATES
Thu 2017–06–15 01:00:00 CEST 14h left Wed 2017–06–14 01:00:04 CEST 9h ago learn.timer learn.service
Thu 2017–06–15 04:54:25 CEST 18h left Wed 2017–06–14 04:54:25 CEST 5h 48min ago systemd-tmpfiles-clean.timer systemd-tmpfiles-clean.service

Be confident

Ok, how these few lines solved my previous problems?

• Reports are in service logs, like any other services, nothing special to do about that and it’s a good thing
• I managed to test how well my service run by calling systemctl start learn.service
• I have a command line that said me when my service last run, when next run is scheduled, etc
• the magic Persistent=yes ensure that if my system was down at scheduled time, job will be triggered as soon as system is up

It was easy, leverage the knowledge I already gathered using systemd for service definition and it’s easy for other people to discover: this time, systemd was a great solution.