4 ms·

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 wh

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.

totony 5y ago
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)
- zeec123 5y ago
  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.
  - totony 5y ago
    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.

totony 5y ago

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)

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