Seeing as the comments seem to have devolved into routine systemd-bashing, I’d just like to say that I enjoyed this submission a lot. I learned about Unsplash’s API, a bit about systemd timers, and was reminded that Linux/FOSS allows users to (relatively) easy create workarounds to lacking functionality and share them.
And here I am, a fool with three screens, who regularly forgets which wallpaper is currently on use on that specific machine because the windows are always covering it.
Especially weird when I think about all the hours I spent customizing my OS/WM and actually making my own wallpapers in the early 00s.
Those are the biggest “just” dependencies to just get a wallpaper. It also uses curl and GLib’s gsettings. That’s probably millions of lines of code… to set a wallpaper.
Systemd timers are basically systemd’s replacement of cronjobs.
It supports all cron features and adds a few fixes which were usually hacked around in crond:
you can use systemctl status to see when will the next timer will run. (In crond people were using crontab.guru)
it prevents cronjobs from overlapping/runnning over each other. (In crond people were using job wrapper which would fork/exec the original command and use a lock file)
it keeps logs of each run for later investigation in journald. (In crond people were using a wrapper to log into a log different log file, or they would use MAILTO=)
I’m biased as a systemd-fanboy, but systemd timers are always a better choice than cronjobs IMHO.
Why is it necessary to create both a .timer and a .service? That seems overkill for just having a service run at specfic times. With cron there is 1 entry.
Creating two files decouples the service definition from the timer definition. If you later want to call the service in another way, for example in response to a path change, you can just add a .path file.
Another advantage of decoupling the service definition from the timer definition is that distro packages can provide the service definitions (in /usr), while leaving to the user/administrator the freedom to enable them or not and to let them run at whatever time they prefer (via timers in /etc) without having to modify the package-installed files.
Package-provided (ana)cron snippets are so cumbersome to modify without creating conflicts with future updates
For example: let’s decide to run foobar daily but at noon. foobar has been installed by the package in /etc/cron.daily. But /etc/crontab says that all daily tasks will be run at 18:00. Too late for me. What should I do?
Remove /etc/cron.daily/foobar? That will cause problems during upgrades.
Modify /etc/cron.daily/foobar with a sleep? That will cause problems during upgrades.
Modify /etc/crontab to run the daily tasks at another time? That will change the time at which all daily tasks run and will cause problems during upgrades.
Add a file to /etc/cron.d? OK, but then how do I stop the cron line in /etc/cron.daily/foobar from being executed?
Thanks to the decoupling of service and timer definitions, I can simply drop
[Timer]
OnCalendar=
OnCalendar=12:00
in /etc/systemd/system/foobar.timer.d/run-at-noon.conf and call it done. No need to change any distro-provided file.
It might seem redundant in this case (and I’d have used a crontab entry too) but if you’re managing many machines it’s convenient to only have on service file on each and vary the timer file contents per machine/role rather than having to keep multiple versions of crontabs in sync.
It’s a massive annoyance. You also can’t have multi-line commands in the service file. The tooling is lacking since you can’t just generate the service and timer files.
I shall henceforth coin the phrase “Unix is in the eye of the beholder” to refer to this phenomenon where, if crontab can’t do something, that’s an opinionated tool following the Unix philosophy, but if systemd doesn’t do it, it’s missing a vital feature.
@acatton never said that systemd supports the MAILTO. They said that it must be used (or overused) if we want to retain the logs from the job, systemd provides us that feature automatically and with logs forwarding it is IMHO much easier and much more resilient to manage than MAILTO incantations.
Seeing as the comments seem to have devolved into routine systemd-bashing, I’d just like to say that I enjoyed this submission a lot. I learned about Unsplash’s API, a bit about systemd timers, and was reminded that Linux/FOSS allows users to (relatively) easy create workarounds to lacking functionality and share them.
And here I am, a fool with three screens, who regularly forgets which wallpaper is currently on use on that specific machine because the windows are always covering it.
Especially weird when I think about all the hours I spent customizing my OS/WM and actually making my own wallpapers in the early 00s.
^ definitely with you there. Launching apps full screen on startup made me forget I even had a background.
Those are the biggest “just” dependencies to just get a wallpaper. It also uses curl and GLib’s gsettings. That’s probably millions of lines of code… to set a wallpaper.
But if it works for you, that’s fine.
On many systems those come already-installed. It’s not like they’re adding much.
I think that using cron instead of systemd would have been more elegant. Still, I like these kinds of little projects.
Systemd timers are basically systemd’s replacement of cronjobs.
It supports all cron features and adds a few fixes which were usually hacked around in crond:
systemctl statusto see when will the next timer will run. (In crond people were using crontab.guru)MAILTO=)I’m biased as a systemd-fanboy, but systemd timers are always a better choice than cronjobs IMHO.
Why is it necessary to create both a .timer and a .service? That seems overkill for just having a service run at specfic times. With cron there is 1 entry.
Creating two files decouples the service definition from the timer definition. If you later want to call the service in another way, for example in response to a path change, you can just add a
.pathfile.Another advantage of decoupling the service definition from the timer definition is that distro packages can provide the service definitions (in
/usr), while leaving to the user/administrator the freedom to enable them or not and to let them run at whatever time they prefer (via timers in/etc) without having to modify the package-installed files.Package-provided (ana)cron snippets are so cumbersome to modify without creating conflicts with future updates
For example: let’s decide to run
foobardaily but at noon.foobarhas been installed by the package in/etc/cron.daily. But/etc/crontabsays that all daily tasks will be run at 18:00. Too late for me. What should I do?/etc/cron.daily/foobar? That will cause problems during upgrades./etc/cron.daily/foobarwith asleep? That will cause problems during upgrades./etc/crontabto run the daily tasks at another time? That will change the time at which all daily tasks run and will cause problems during upgrades./etc/cron.d? OK, but then how do I stop the cron line in/etc/cron.daily/foobarfrom being executed?Thanks to the decoupling of service and timer definitions, I can simply drop
in
/etc/systemd/system/foobar.timer.d/run-at-noon.confand call it done. No need to change any distro-provided file.Yes, but when it is a service that only makes sense as a timer, it’s just putting the information in multiple places.
It might seem redundant in this case (and I’d have used a crontab entry too) but if you’re managing many machines it’s convenient to only have on service file on each and vary the timer file contents per machine/role rather than having to keep multiple versions of crontabs in sync.
It’s a massive annoyance. You also can’t have multi-line commands in the service file. The tooling is lacking since you can’t just generate the service and timer files.
You can’t have multi-line commands in crontabs, either.
I shall henceforth coin the phrase “Unix is in the eye of the beholder” to refer to this phenomenon where, if crontab can’t do something, that’s an opinionated tool following the Unix philosophy, but if systemd doesn’t do it, it’s missing a vital feature.
You can have multiple commands per cron entry
Or do you literally mean commands split across multiple lines?
So?
You can also have aby number of
ExecStartPreandExecStartPost, if suitable.As far as I know,
MAILTOis exactly a feature that it doesn’t support.Disregarding that this deficiency can be hacked around.
@acatton never said that systemd supports the
MAILTO. They said that it must be used (or overused) if we want to retain the logs from the job, systemd provides us that feature automatically and with logs forwarding it is IMHO much easier and much more resilient to manage thanMAILTOincantations.I’m disproving this overly bold, careless statement that you might not have noticed:
I can’t imagine anything easier to use than
MAILTO. Set it once, everything becomes monitored.