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.
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.
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.
> But now obviously we were so blind and wrong all this time and the only true solution is of course systemd.
Oh nooooo... I've been so wrong. Seen the direction most Linux distro took I decided to move to VMs (VMs which runs systemd-less systems), OCI containers (where by definition PID 1 is not systemd) and now an hypervisor to run systemd Linux VM but I'm now into... An hypervisor that is precisely not Linux (so no systemd at all).
I sinned. So now maybe it's time to buy Microsoft stocks, praise Windows [ini] config files, and venere the Linux PID 1 god with its tentacles meddling with every part of the Linux system.
> 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.
> that doesn't mean that cron is the solution that needs to accompany us until the heat
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
> 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.
On the other hand, it is a consistently heard argument when debating why the year of the Linux adoption on desktop hasn't happened yet is that there are too many standards, too many cooks. And I kinda agree with that, packaging software for multiple distributions is a hot mess, especially if you're shipping daemons. systemd is at least one worry less, it's a stable API that can be used for all purposes.
Again, this isn't as black-and-white as it seems on a cursory review.
From the perspective of someone who hates anti-rooting measures on phones, anything moving into the direction of trusted computing is bad.
But from the perspective of someone, say, in Russia, Iran, the US or Germany who might be a journalist or political activist? Suddenly, a way for the OS to attest if the hardware hasn't been manipulated in an evil maid scenario and that any successful attempt of exploiting an OS vulnerability at runtime can be reverted by a simple reboot becomes extremely vulnerable.
My personal opinion, we need strong and good attestation capabilities for a multitude of use cases. But we also need good laws that protect user freedoms, similar to "right to repair" laws we need "right to root" laws that ban applications from requiring unrooted phones.
systemd-as-pid1 is good. I have to admit that. I will not go back to syvinit unless a good reason comes up.
However absolutely fuck all the metastasis surrounding systemd and the shit inside, timers included.
> we need strong and good
Yeah this is true.
Problem is, this technology will absolutely be used for limiting your access to the internet from a distribution that was modified. Thus leading to locked down personal computers.
> However absolutely fuck all the metastasis surrounding systemd and the shit inside, timers included.
Meh. systemctl list-timers is orders of magnitude better than trying to wade through /etc/crontab, /etc/cron.{hourly,daily,monthly,weekly,yearly} and whatever else non-Debian distributions come up with, and cron's arcane syntax is a mess on its own on top of that. Especially if you try to run a cronjob as not-root.
> Problem is, this technology will absolutely be used for limiting your access to the internet from a distribution that was modified. Thus leading to locked down personal computers.
That's a hypothetical threat IMHO. DRM and Cloudflare Turnstile [1] are actual threats that are far bigger in practical usage.
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.