Yet there's always something new to learn and actually consider as another useful tool.
Like imagine trying to explain systemd timers and services and unit files to a beginner.
I think it's... easier? Like "systemd is the place where your system manages all the processes it needs to run. Part of those processes can be run on a schedule, or on a timer, and you define them using this simple text file".
It is also easier to debug as every job gets its own log rather than trying to write to system mailer nobody had set up with the job errors
Why? It's one of those fuzzy and somewhat hard to explain things. The systemd approach just maps more cleanly to my mental model of "how things should work" I guess. And maybe some of it is that I did indeed experience plenty of " Ambiguous $PATH settings make cron script execution difficult to predict" in the past, although it's not just that.
I won't sit here and claim that systemd timers are necessarily better than cron in any universal / objective sense. But they've won me over, for what it's worth.
that and cron always felt fragile too with a lot of quirks and limitations you had to work around instead of being a robust thing from the start.
But that's because I'm old because obviously systemd-* is the only right way and everyone else who see things differently is a pundit.
I have done scheme all my life, which is why I prefer shepherd. Not only is it in a syntax that i can use elsewhere, I get completion in Emacs.
But now obviously we were so blind and wrong all this time and the only true solution is of course systemd.
Coz it's looks crazy complicated to set them up.
I am not the biggest fan of systemd, but today I will always reach for a systemd timer over cron simply due to the sheer amount of bad experiences I've had with cron. Hours upon hours wasted trying to troubleshoot crons that weren't working due to some stupid obscure issue, having to use dirty hacks to monitor for success or retry failed jobs.
A few years ago I was trying to run a very simple bash script with cron and the script just died halfway through for no reason. Nothing in logs, worked fine when run directly, but in cron it just stopped halfway through a loop. Never figured out the cause, just gave up and used a timer instead, which worked fine. Never touched cron again after that.
The ease and convenience of monitoring and troubleshooting alone are worth switching over.
Once you learn that env in cron is not same as in your shell and once you learn to redirect output to loggers - it works just fine.
It would be a lie to say that I never debugged cron and sure it's annoying.
> and the script just died halfway through for no reason
Unrelated to cron. Bad script.
We are all guilty of making bad scripts, bash is a disgusting degenerate language (and I love it). The way we learn to write good scripts is by writing bad scripts in enough amounts to get bitten by all the warts.
One thing I really love about cron, is that if you set up mail on the server (which: you should btw), then cron actually sends emails if it sees anything in stdout and stderr.
I am a dyed in the wool systemd non-believer, but I really do like the timers.
> Unrelated to cron. Bad script
Again, worked fine when run manually, worked fine in a systemd timer. Pretty sure I still have it running today and it continues to work fine without ever failing.
Come on, dude. That's unnecessarily polemic.
cron et al have served us for decades, yes. But that doesn't mean that cron is the solution that needs to accompany us until the heat death of the universe or year 2038, whatever comes first.
I agree, the systemd folks haven't exactly been the best when it comes to PR or when it comes to being even near feature parity with what they tried to replace. But now, they aren't just at feature parity, they surpassed plain old cron.
Maybe it is time to lay cron to rest, at least slowly.
Yeah I agree.
> systemd folks haven't exactly been the best when it comes to PR
It's deeper than that. Systemd folks are enemies of Linux. First, it's "fuck your opinion, do as we say" attitude which makes me want to throw away everything that comes from that poisonous well. Second, it's the embrace and extinguish strategy employed by the systemd project. And third, systemd author is up to no good: https://news.ycombinator.com/item?id=46784572
And in fact I do have a use-case for needing to run something ~5 minutes after the system boots and then every ~12 hours onward from there. It's great that systemd timers has me covered!
I wish documentation for tools would explain their abstractions concepts in terms of its primitives.
Great post, thanks!
[Service]
Type=oneshot
WorkingDirectory={{ home }}/current/
Environment=RAILS_ENV=production
ExecStart=/bin/sh -lc "bin/db-backup --verbose"
[Service]
Type = oneshot
WorkingDirectory = %h/current/
Environment = RAILS_ENV=production
ExecStart = /bin/sh -lc "bin/db-backup --verbose"I find myself doing this sort of thing all the time..
Environment = MULTIPLE=environment VARIABLES="in single line"Over all I think Systemd get way to much criticism. You don't have to use all the parts, but if you care to go through the documentation you'll find interesting features such as journald log-shipping and systemd-machined which can manage containers and VMs.
If I never recall hacking in ulimit calls in the top of buggy shell scripts for crappy old services that done respect pam_limits it won’t be soon enough.
Could have been YAML.
Could have been XML.
It would also make it much simpler to make good GUI editors for the files instead of the Notepad approach most unix config files take.
https://www.freedesktop.org/software/systemd/man/latest/syst...
XML is that wonderful format that gave us vulnerabilities like death by million laughs, up to a certain moment, you could MitM DTDs, and a whole slew of everything-XML stuff back when XML was like AI is today, none of which I miss today.
Oh, and remember times when programmers would argue whether argument order in XML files should be significant or not?
But XML books with their idealized XML future description did give me the same warm fuzzies as some intricate clockwork mechanism to a Victorian geek.
Could have been XML Property Lists.
ducks
Now you get to look around the myriad of places where you can put systemd files, and figure out which ones are base services and which ones are custom, with no general convention to go about it. Nope.
With —-all