Hacker News Reader

Comment by 5e92cb50239222b | Hacker News Reader

You mean systemd timers?

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.

View on HN

What I really like is that systemd can tell me when the next execution will happen. One typo in the awful crontab format and your job will never execute with no way of testing it.

My favorite feature of systemd timers is that they get triggered when the time is set by NTP on boot. Combine that with a system without an rtc and a timer to reboot the system every week. It just works.

Another one that can't be done easily with cron: when your system boots and an execution was missed, systemd timers can be told to run it

Cron has all these features:

- 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)

There are some cool features in systemd that are not easy to do in cron.

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.

Redhat made the scripting for you. I don't think it's that complicated of a script (although it would be easier with a retry command)

    sleep $random
    for i in 1 2 3 4; do
      backup && exit 0
      sleep 15m
    done
    logger "backup failed"
    exit 1

add script to @startup in crontab or whatever they use. You can use another wrapper that only execute it if the backup is newer than now-24h. Backup could even be remote and you could track it by touching a file in /var

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)

No, you are maybe 80% there. - Your logger does not send a mail with the restic logs to me. - How do I check that the backup is newer than 24h? I have to make sure the last backup succeeds. - Do I have to touch a file in /var for every backup script? When do I touch it? After the backup run, before? What if I shutdown my laptop during the backup?

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.

Well it's not a hypothetical solution, the script is probably about the same length as the timer config.

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.

Reply on news.ycombinator.com