Refreshing to see a positive opinion with regards to systemd. Incidentally, my favorite way to spawn jobs, is well, the job spawn command in nushell.
Love systemd timers
221–230 of 309 posts
Re: Love systemd timers
#222Earlier quoted context omitted.
+1, NixOS makes working with systemd a breeze. Defining units in Nix beats wrangling INI files. systemd.services.sync-recyclarr = { serviceConfig.Type = "oneshot"; path = [ pkgs.podman ]; script = '' podman exec -it recyclarr recyclarr sync radarr podman exec -it recyclarr recyclarr sync sonarr ''; }; systemd.timers.sync-recyclarr = { timerConfig = { OnCalendar = "daily"; Persistent = true; Unit = "sync-recyclarr.ser…
I don't currently have a personal use-case for container services, but Quadlets are another example of systemd (and podman) beauty. It looks like someone has gone through the trouble of making the OS+home-manager modules: https://github.com/SEIAROTg/quadlet-nix
I never had the opportunity to try out quadlets, but they seem powerful.
I maintain one of the competitors listed in that README (compose2nix), so I am a bit biased haha.
For now, I prefer the ability to interop with Compose.
Re: Love systemd timers
#223Re: Love systemd timers
#224Hey everyone, author here. I spotted the hn traffic a little late but I'm happy for any feedback or comments and will try and address the top-level comments as I can.
(Aside: I wrote this article early last month but it caught on only just recently. For better or worse, touching a third rail topic like systemd seems like a sure-fire way to elicit strong and numerous reactions both positive and negative.)
Re: Love systemd timers
#225This is a very good intro to systemd timers -- I think you convinced me to finally start using them. Love the "list-timers" thing as well. With cron, it never seemed easy to me to get a picture of all the cron jobs running on a box. I'd need to check crontab for all users, as well as /etc/cron.d/, as well as the daily/hourly/monthly directories. And in fact I do have a use-case for needing to run something ~5 minutes…
Thanks for the kind words! Especially given how ubiquitous systemd is now, skilling up on the toolbox with commands like `systemd-analyze` and `systemctl list-timers` feels super valuable.
Re: Love systemd timers
#226> stdout and stderr output often ends up in a black hole Ain't that the truth. Literally every crontab I've written for the last 10 years has had this in it: 2>&1 | logger -t cron-WHATEVER ...and that does a pretty good job of capturing anything that the script emits and making it easy to grep for in syslog the following morning. But I'm still amazed at how many crontabs I run across that don't capture any output at…
The “standard” is for the output to go to your user’s mail box. You know, that thing you check with the “mail” command and has a user interface shockingly similar to `ed`. You check that all the time, right? Right?
It’s… certainly a product of its time. (I have my system mailer set up to actually send mail to my Gmail account, with authenticated SMTP via API keys, which I did 15 years ago and have no recollection of how I even did it. It still works… somehow. I don’t even use Gmail any more, and I’ll be damned if I have to figure out how to do it with fastmail, and lord knows doing unauthenticated old-school SMTP is just gonna get sent to fastmail’s black hole, so that idea ain’t gonna work either.)
Re: Love systemd timers
#227Earlier quoted context omitted.
That's simple but consider "run something 4x per day but randomize a delay by hour so all of the 200 servers doing that task won't run it all at once" In cron, you basically have to either use your configuration management to generate those times, or have a random delay script running before the command In systemd timers, it's just OnCalendar=0/6:00:00 RandomizedOffsetSec=60m and the offset generated will be stable f…
> In cron, you basically have to either use your configuration management to generate those times, or have a random delay script running before the command Nope. From crontab(5) The RANDOM_DELAY variable allows delaying job startups by random amount of minutes with upper limit specified by the variable. The random scal‐ ing factor is determined during the cron daemon startup so it remains constant for the whole run t…
still not a thing in vixie cron installed by default in Debian in 2026.
I'll take payout from your lost bet now
https://dyn.manpages.debian.org/experimental/cron/crontab.5....?
Re: Love systemd timers
#228I haven't used systemd timers enough to disagree, but > Ambiguous $PATH settings make cron script execution difficult to predict. What makes you say that? You can set the PATH right in the crontab. Is that harder to "predict" than it being set in /etc/bashrc, ~/.bashrc, ~/.profile, ~/.bash_profile, /etc/systemd/…, or wherever else? > You might feel cool knowing the scheduling grammar by heart I've used Linux since 19…
> But luckily it's pre-printed in the crontab
man 5 crontab
Re: Love systemd timers
#229I've been using Linux for over 20 years, systemd for over 10. Yet there's always something new to learn and actually consider as another useful tool.
I'm using Linux for about 30 years and apparently we were all wrong using cron for decades.
Not wrong, but there’s room for improvement!
Re: Love systemd timers
#230systemd is complex on first view, but after using it you didn't want to use anything else. It's handy to manage everything using systemctl
There are still some weird things/choices in its design I don't fully understand. For example, why do unit definitions have to be actual files on disk? Then, all of these files are reloaded when the daemon reloads, not just changed ones. But, why couldn't there be an API letting me add units programmatically? (There kind of is but it's constrained/inflexible) Or, why can't I declare multiple units in the same file? I…
You can add units programmatically. Google it!