Hacker News Reader

Comment by MawKKe | Hacker News Reader

Related note: with systemd you are probably better off using its OnCalendar facilities. There is even a tool called 'systemd-analyze', which can be used for verifying the correctness of your OnCalendar timespec:

    $ systemd-analyze calendar "*:11/5" --iterations 3
      Original form: *:11/5                      
    Normalized form: *-*-* *:11/5:00             
        Next elapse: Mon 2021-08-30 23:21:00 EEST
           (in UTC): Mon 2021-08-30 20:21:00 UTC 
           From now: 47s left                    
           Iter. #2: Mon 2021-08-30 23:26:00 EEST
           (in UTC): Mon 2021-08-30 20:26:00 UTC 
           From now: 5min left                   
           Iter. #3: Mon 2021-08-30 23:31:00 EEST
           (in UTC): Mon 2021-08-30 20:31:00 UTC 
           From now: 10min left

View on HN

That's a really interesting idea that wasn't on my radar. We make extensive use of cron, including fairly complicated job wrappers to do things like provide status to our monitoring system and prevent running the same job multiple times in parallel. I like to break these out into actual shell scripts if it gets too complicated, but some of these things might be simplified through using systemd units and timers. Plus we could gain some additional functionality, like chaining jobs, which we currently do with "This job shouldn't run more than X minutes, so schedule the follow on job +X minutes from the last one". Plus, do I understand you can schedule jobs on the second?!? :-)

Like many things in systemd, timers are a bit complex, I always find myself opening 2-3 manpages at once when doing one. But when you get them set up, it's just a much better system. I still use cron for basic one-liners, but that's it.

Systems timers do not allow jobs to overlap which is a nice feature vs wrapping a cron on flock

The randomisation features of systemd timers are pretty essential, to avoid lots of systems running the same thing at the same time. To do that in cron you have to do ugly things like use bash and then run sleep $RANDOM.

Several cron implementations (including the default in Red Hat-derived distributions) have a built-in RANDOM_DELAY variable you can set.

I prefer setting the random offset when writing/deploying the crontab (you probably have them committed somewhere so there's bound to be a deployment mechanism, such as ansible). This way the offset is kept constant, while still avoiding the "thundering" cron.

Is there a way yet for systemd to send emails on timer failures or their output?

Reply on news.ycombinator.com