upvote
Thank Lennart you degenerate apostates are finally starting to see the light of His glorious creation. Hallowed be thy systemd-journald.
reply
After reading this article I'm convinced that what we need is systemd timers fronted by a vibe coded crontab -e emulator.

Coz it's looks crazy complicated to set them up.

reply
Has it actually served you well? Because it hasn't served me well at all.

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.

reply
Let me state once again: "within its very clear limitations".

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.

reply
Systemd will reign supreme for a millennium if the answer to every question or complaint about non-systemd tools is "you're holding it wrong".
reply
As a user I'm kinda whatever about the tools because the answer to my complaints about systemd is also "you're holding it wrong."
reply
I'm sympathetic, but "bad script" is an awful assertion.

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.

reply
I don't agree that these are just limitations. The fundamental problem cron tries to solve is very simple: I want to run a program automatically at specific times. There are probably many features of systemd timers that can be considered niche or extraneous in solving this problem, but the ability to easily know when the program last ran and what its exit code and stderr output were is not one of them. I believe that if an alleged solution to this problem doesn't provide at least this, it's not really solving the problem.

> 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.

reply
So basically it took you decades to learn all the bugs, UX issues and problematic quirks and now you're complaning someone built something better? :)
reply
> But now obviously we were so blind and wrong all this time and the only true solution is of course systemd.

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.

reply