5 ms·

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 ver

by MawKKe 5y ago

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

deleted 5y ago
[deleted]
linsomniac 5y ago
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?!? :-)
- x0 5y ago
  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.
- aprdm 5y ago
  Systems timers do not allow jobs to overlap which is a nice feature vs wrapping a cron on flock
pabs3 5y ago
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.
- xorcist 5y ago
  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.
rhn_mk1 5y ago
Is there a way yet for systemd to send emails on timer failures or their output?

by MawKKe 5y ago

deleted 5y ago

[deleted]

linsomniac 5y ago

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?!? :-)

x0 5y ago
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.
aprdm 5y ago
Systems timers do not allow jobs to overlap which is a nice feature vs wrapping a cron on flock

pabs3 5y ago

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.

xorcist 5y ago
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.

rhn_mk1 5y ago

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