My favorite metonymic technology term is “cron job”: even though
cronmay not literally be the daemon that executes actions on a schedule, we apply the term to anything that walks like acronand quacks like acron. As Patrick McKenzie likes to point out, cron jobs are one of the most eminently useful computing primitives. They offer utility that’s almost immediately obvious for plenty of use cases that almost everybody has: do this every day; do that once a month.And yet. You probably shouldn’t use literal
↫ Tyler Langloiscron(or its more modern cousins) for scheduled tasks! In 2026 there are more modern options available, and my favorite is the humble systemd timer. I love systemd timers. If you don’t love them yet, maybe I can show you the reasons why you should love them, too.
These are just timers. They are not consuming your computer or taking over the open source world. They do not phone home to Red Hat. These are just timers.
I’ve had so much more success working with systemd timers to get work shit accomplished than I ever did with good old fashioned cron. There were complicated things I couldn’t get working with cron _even though it’s hypothetically simpler_ that “just worked” with systemd timers.
*accepts his shill check from Big Hat*
Same here. Conceptually, philosophically, and religiously I don’t have a problem with systemd. Yes, it’s more complicated and has a bigger codebase than other init systems, mainly because it’s not just an init system. But if you think about it there’s nothing simple about the functionality achieved in any capable modern OS, and I personally think that any good OS should abstract away its core complexities and present an interface that allows the end user (or admin) to easily make actual features *work* the way they want, without needing to understand the esoteric low-level components. For me, systemd timers get the job done, and as the article mentions they do so with some additional features and reduced complexity **for the end user**. I also have had great results with mounting SMB shares via a systemd.automount unit; that method has proved to be somewhat easier and much more reliable than autofs, which used to even cause temporary freezing/hanging of the entire system.
My only major complaint with systemd is how it was originally presented as having advantages to make the system boot faster. But in actual practice, my custom-installed fairly minimal Debian system boots on my Intel i7 laptop with NVMe storage in about the same time as a well-optimized Upstart or sysvinit system used to do 15 years ago on my Celeron laptop with spinning rust. And don’t get me started on the *long* hangs for “A stop job is running for …” during shutdown.
rahim123,
Ah, it’s not just me then… I absolutely hate that. No option to forcefully stop the job or anything. And the message often doesn’t give enough information to identify the culprit. Hopefully most people don’t encounter it because it’s very unfriendly when it occurs.
In a VM scenario it can double the frustration because it takes place recursively. I believe it may be caused by some kind of network race condition as things are shutting down. I’m planning on reinstalling everything soon, maybe it will go away.
Definitely not just you. Both startup and shutdown on any systemd based OS I run are slow, and many times shutdown just hangs for several minutes and I end up having to force reboot or shutdown. This isn’t such a big deal on a local machine; the hang is typically after the drive writes are finished so I can just force it with the power or reset button. I absolutely don’t trust systemd on remote servers though, because I’ve been burned several times in the past by this long-standing bug that Lennart and team refuse to acknowledge and fix. Fortunately I do have out of band control over our web and email VPS, so when AlmaLinux inevitably hangs during a reboot I can step in and flip the virtual switch.
As someone who doesn’t really have any strong opinion about systemd, other than it is so complicated that i am happy i don’t really have to fiddle with it often, but old init scripts were not fun either so not much difference. But i have to say, that is a whole lot of moving parts and steps for something that used to just be simply adding a line to a file or adding a file in a directory. Yes, maybe the old format is not beautiful, but it was simple to learn, and much less boilerplate.
I don’t mind that the world evolves and we get new tools, but i find it really sad that simple things keep getting harder while hard things are still hard.
So it has more features, but personally i don’t want it to have all kind of logic build in, i would like to encapsulate that in whatever script i have it call.
One of these days I really need to get around to writing a systemd timer equivalent to the firejail profile generator I wrote and then, with the boilerplate of creating new systemd timers suitably mitigated, migrate all my cronjobs over to it.
I like the *features* of systemd timers. Still on the learning curve to actually use them competently!
They are great, but I wish I could put both halves (service and timer) in a single file.
That is a non-trivial part of what I mean by “boilerplate” when I talk about procrastinating using them instead of crontab pending writing a tool to generate them.
Fun fact, [[ $(($RANDOM % 10)) == 0 ]] code is wrong, it has slightly more than 1/10 chance of occurring due to actual range of $RANDOM not being cleanly divisible by 10.
Sorry, but “It’s just timers” is exactly what it is not. I can get behind neat timers. But if it’s just timers, why do my timers have to be part of a bloated monstrosity that absolutely is consuming my PC and also insists on being in charge of my network configuration, name resolution, bootloader, time sync, login management, all log files and temp files, display brightness, kernel configuration, container and vm management, etc etc etc?
I do not strongly object to any of the components of systemd on their own, it is the integration that is the problem. A truly open system should allow freedom to choose different and often superior, or simpler, solutions that are available in every area I listed above, without bundling every system service into an unwieldy, overly complex monolith. It’s also stodgy and corporate. Whenever I use a non-systemd environment like FreeBSD, it is such an wild breath of fresh air (Wait, I can just…. _look_ at a log file? Wait, I can just… _choose_ between alternatives?)
People say that systemd manages to work all right, and it does. People can get used to it and often prefer to have a fully packaged solution dropped in their lap. I have no doubt that it makes releasing certain apps across linux distros easier. It has its strengths. I don’t judge anyone for their preferences. But systemd is still a bad direction for OS architecture and is quietly gutting the hybrid vigor and distro diversity that are one of the key strengths of the Linux ecosystem. No offense to the neat timers.