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.

▲

egorfine an hour ago | parent [-]

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.

▲

erxam an hour ago | parent | next [-]

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

	▲	dogleash 40 minutes ago \| parent [-]
		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."

▲

dijit an hour ago | parent | prev | next [-]

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.

▲

bakugo an hour ago | parent | prev | next [-]

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.

▲

izacus an hour ago | parent | prev [-]

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? :)