4 ms·

We have used cron perfectly fine for decades and it served us well within its very clear limitations. But now obviously we were so blind and wrong all this tim

We have used cron perfectly fine for decades and it served us well within its very clear limitations. But now obviously we were so blind and wrong all this time and the only true solution is of course systemd.

bigbuppo 5mo ago
Thank Lennart you degenerate apostates are finally starting to see the light of His glorious creation. Hallowed be thy systemd-journald.
bakugo 5mo ago
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 5mo ago
  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.
  - dijit 5mo ago
    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.
  - izacus 5mo ago
    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? :)
  - erxam 5mo ago
    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 5mo ago
      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."
  - bakugo 5mo ago
    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.
  - imtringued 5mo ago
    If the script is bad, surely cron will give you a way to test that? Right? Right??????
    - egorfine 5mo ago
      well yes but actually no
mschuster91 5mo ago
> 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.
- egorfine 5mo ago
  > 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 https://news.ycombinator.com/item?id=46784572
  - mschuster91 5mo ago
    > 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. > And third, systemd author is up to no good: https://news.ycombinator.com/item?id=46784572 https://news.ycombinator.com/item?id=46784572 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.
tim-projects 5mo ago
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.
TacticalCoder 5mo ago
> 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. Or not.

bigbuppo 5mo ago

Thank Lennart you degenerate apostates are finally starting to see the light of His glorious creation. Hallowed be thy systemd-journald.

bakugo 5mo ago

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 5mo ago
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.
- dijit 5mo ago
  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.
- izacus 5mo ago
  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? :)
- erxam 5mo ago
  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 5mo ago
    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."
- bakugo 5mo ago
  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.
- imtringued 5mo ago
  If the script is bad, surely cron will give you a way to test that? Right? Right??????
  - egorfine 5mo ago
    well yes but actually no

mschuster91 5mo ago

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

egorfine 5mo ago
> 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 https://news.ycombinator.com/item?id=46784572
- mschuster91 5mo ago
  > 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. > And third, systemd author is up to no good: https://news.ycombinator.com/item?id=46784572 https://news.ycombinator.com/item?id=46784572 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.

tim-projects 5mo ago

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.

TacticalCoder 5mo ago

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