This week I have just learned that systemd has an alternative scheduler in addition to cron.
At this rate systemd will probably become another new OS on top of Linux similar to Android.
At this rate systemd will probably become another new OS on top of Linux similar to Android.
https://wiki.archlinux.org/title/Systemd/Timers
They were always there, and they work much better than cron in my experience (you're not forced to use cron expressions because it supports things like human-readable time formats; they can randomize startup times, which is useful for backups; they can put additional constraints (like "start only if network is available"); and they can actually be controlled from a single place (systemctl list-timers) instead of cron files that can be spread across multiple configs and directories in /etc/cron*, and pretty much every single user profile).
It's a tiny slice of functionality and it makes a lot of sense to keep it in the service manager.
Try harder next time.
- single place control: crontab -e
- additional constraints: systemctl status && scirpt.sh
- randomize startup times: sleep ${RANDOM:0:MAX} && script.sh
The nice thing is that it integrates with the existing infrastructure (shell scripts). This means you don't have to add code to cron to add features.
I agree with the 10s of files in /etc/cron.daily, etc. But those are there for convenience (you can even remove them from /etc/crontab)
Example: I use restic backup. One timer runs every 24h or on the next boot if there where more than 24h since the last backup as this is a laptop. Also it waits some random amount so that not all script run at the same time after boot. If a backup fails (eg remote server down) it retires every 15min, but no more than one hour before I get an Mail with a detailed report.
All really easy in systemd. No scripting required.
sleep $random
for i in 1 2 3 4; do
backup && exit 0
sleep 15m
done
logger "backup failed"
exit 1
Yes systemd might be slightly easier, but that's because they put a lot of money into systemd, not because systemd is a better architecture. It's nice that they open sourced it (although it does give them a competitive edge), but we can't act like what used to be there isn't as good.
Someone could have packaged utility wrapper scripts in much less time than it did to add those features to systemd, and these wrapper script would be more widely usable (by init scripts, cronjobs, etc)
These corner cases take exponentially more time to get right than the first 80%.
"Someone could have packaged utility wrapper scripts in much less time than it did to add those features to systemd"
But nobody has, and I am exhausted to hear how easy it is without systemd without offering a non-hypothetical solution. You don't like systemd, then do not use it and move on. There are distributions without it.
I used logger because it's better practice to log and for the logger to send email, you can send email using the mail command or msmtp. The timing was omitted because it is trivial and didnt serve to illustrate the point, just do backup && touch /var/lib/lastbackup && exit 0, with a if at the start of the script like if [ -x "$(find -mtime -1 /var/lib/lastbackup)" ]
The mid-backup shutdown is a property of the backup script, you'll have to consider that even using systemd.
Sadly there are not many distros without systemd. Everyone is strained in resources and Redhat is pumping money into the ecosystem, so it's really easy to take over most of it. Like I said I don't dislike systemd, I think it adds value, but it's just not the best solution since it does not integrate with others well.
EDIT:
>You don't like systemd, then do not use it and move on.
But this is the issue with systemd: you can't. Want gnome? needs dbus, which needs logind which is systemd. Need libvirt? also needs dbus. Need Y? Needs systemd-tmpfs, which packages the whole systemd as a dependency. Same thing for systemd-udev.
The interlock is so brutal most distros are forced to switch because they can't handle the dev burden.
> systemd-timesyncd does no clock discipline: the clock is not trained or compensated, and internal clock drift over time is not reduced. It has rudimentary logic to adjust poll interval but without disciplining the host will end up with uneven time forever as systemd-timesyncd pushes or pulls at whatever interval it thinks the near-term drift requires. It also can't assess the quality of the remote time source. You're unlikely to get accuracy much greater than 100ms. This is sufficient for simple end user devices like laptops, but it could definitely cause problems for distributed systems that want greater time precision.