[vidarh]

Most of what he's writing about, and much more, is made substantially easier with systemd timers.

E.g. want errors to cause e-mails, but everything else to just go to logs? Use a timer to activate a service, and make systemd activate another service on failure.

Want to avoid double execution? That's the default (timers are usually used to activate another unit, as long as that unit doesn't start something that doubleforks, it won't get activated twice).

(Some) protection against thundering herd is built in: You specify the level of accuracy (default 1m), and each machine on boot will randomly select a number of seconds to offset all timers on that host with. You can set this per timer or for the entire host.

And if you're using fleet, you can use fleet to automatically re-schedule cluster-wide jobs if a machine fails.

And the journal will capture all the output and timestamp it.

systemctl list-timers will show you which timers are scheduled, when they're scheduled to run next, how long is left until then, when they ran last, how long that is ago:

     $ systemctl list-timers
    NEXT                         LEFT     LAST                         PASSED       UNIT                      
    Sat 2015-10-17 01:30:15 UTC  51s left Sat 2015-10-17 01:29:15 UTC  8s ago       motdgen.timer             
    Sat 2015-10-17 12:00:34 UTC  10h left Sat 2015-10-17 00:00:33 UTC  1h 28min ago rkt-gc.timer              
    Sun 2015-10-18 00:00:00 UTC  22h left Sat 2015-10-17 00:00:00 UTC  1h 29min ago logrotate.timer           
    Sun 2015-10-18 00:15:26 UTC  22h left Sat 2015-10-17 00:15:26 UTC  1h 13min ago systemd-tmpfiles-clean.timer

And the timer specification itself is extremely flexible. E.g. you can schedule a timer to run x seconds after a specific unit was activated, or x seconds after boot, or x seconds after the timer itself fired, or x seconds after another unit was deactivated. Or combinations.

[rnhmjoj]

I agree: I recently moved my scripts from crontab to systemd timers and there is no going back. Finally I have a proper way to debug and log. Also on NixOS I can have the unit file and timer generated in very few lines. Look at this one for example:

    "xkcd" = {
       description = "send latest xkcd comic"; 
       wants = [ "network.target" ]; 
       startAt = "Mon,Wed,Fri *:0/30"; 
  
       path = with pkgs; [ telegram-cli ];   
       serviceConfig = { 
         User = "rnhmjoj"; 
         Type = "oneshot"; 
         ExecStart = "${cabal}/bin/xkcd"; 
       };
     } // basicEnv;

[eru]

It's a fun example, but for webcomics RSS is probably the better solution than scheduling something on your machine.

[2bluesc]

This. While certain crowds like to hate on systemd, the many features beyond init are lost in the noise for the casual observers. I love systemd timers.

The biggest shortcoming with systemd timers, is that it doesn't have an easy way to notify admins of failures like standard cron does.

I tried to hack around this[0], but it still feels wrong.

[0] https://github.com/kylemanna/systemd-utils#scripts