4 ms·
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
by bhaney 2y ago
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.
- burnJS 2y agoI pair crons with healthchecks.io
- chatmasta 2y agoIt would be cool if someone made a crontab interface to systemd timers. Use crontab syntax but generate systemd boilerplate with sane defaults.
- bhaney 2y agohttps://wiki.debian.org/systemd-cron https://wiki.debian.org/systemd-cron
- 1una 2y agoIMO Systemd Timers provide much better control over how the cron job is run. Need to distribute lots of cron jobs evenly to avoid overloading the system? Use RandomizedDelaySec. Some cron jobs are flaky and you want to re-run if it fails? Add Restart=on-failure to corresponding service. Some cron jobs conflict with each other? Set Conflicts=foo.service or maybe Before & After. Sure, all above are possible with shell scripts. But systemd provides a standard, reliable way to define these properties.
- bhaney 2y ago> Systemd Timers provide much better control over how the cron job is run Yes, they do. And as the very first sentence in my comment says, I like systemd timers when they're appropriate. None of the features you've mentioned were used in the author's solution, which is the sole thing I'm arguing against.
- Ferret7446 2y ago> Much more significantly, the amount of setup involved in a systemd timer is way higher than putting a line in a crontab Counterpoint: this requires root, while you can edit and run systemd timers without root. Thus it's also generally more secure, both when creating the job and every time it runs. > 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. You could write a script to automate it, if it's such a big deal. Creating timers/cronjobs isn't something that needs to be done often enough for this to matter. If it is, another counterpoint: systemd supports creating transient timers, which you could do programmatically. And final counterpoint: you can make systemd understand crontab and convert it into timers (systemd-crontab-generator)
- bhaney 2y ago> Counterpoint: this requires root Counter-counterpoint: No it doesn't? Running `crontab -e` as a non-root user will edit that user's crontab, and running it as root will edit the system crontab. Cron can be configured to deny users their own crontabs, but every common distro I'm aware of defaults to allowing user crontabs. > You could write a script to automate it, if it's such a big deal Or I could not bother with that and just use cron? > another counterpoint: systemd supports creating transient timers What is this a counterpoint to? That the author's particular use case of running a backup script once a day is a task better suited to cron than systemd timers? I'm not sure how transient timers are even relevant here, much less a counterpoint.
- rascul 2y ago> Running `crontab -e` as a non-root user will edit that user's crontab, and running it as root will edit the system crontab. Running it as root will edit the root user's crontab (in /var/spool/cron), which is separate from the system crontab (/etc/crontab), which has a slightly different format.
- 2y ago