3 ms·

> forget cron Sure. It worked for _50 years_ just fine but obviously it is very wrong and should be replaced with - of course - systemd.

MyOutfitIsVague 1y ago
Timers are so much better than cron it's not even funny. Managing Unix machines for decades with teens of thousands of vital cron entries across thousands of machines, the things that can and do go wrong are painful, especially when you include more esoteric systems. The fact that timers are able to be synced up, backed up, and updated as individual files is alone a massive advantage. Some of these things that "worked for 50 years" have also actually sucked for 50 years. Look at C strings and C error handling. They've "worked", until you hold them slightly wrong and cause the entire world to start leaking sensitive data in a lesser-used code path.
- egorfine 1y ago
  > have also actually sucked for 50 years I agree with you, that's exactly right. Not sure I'm on the same page with you on the cron. I have a similar experience but I'd rather say that cron was something that never gave me headaches. Unlike obviously systemd.
  - MyOutfitIsVague 1y ago
    Cron has given me a ton of headaches. Between skipped jobs on reboots and DST, inability to properly express some dates ("First Sunday of the Month" is a common one), and worst of all, complete inability to prevent the same job from running multiple times at once, it's been regular headaches for a shop who has leaned very heavily on it. Some cron daemons handle some of these things, but they're not standard, and AIX's cron daemon definitely doesn't have these features. Every job has to be wrapped in a bespoke script to manage things that systemd already does, but much worse. systemd has given me many headaches, but as a whole, it has saved me far fewer headaches than it has given me.
    - egorfine 1y ago
      > skipped jobs on reboots and DST > prevent the same job from running multiple times I'd say these are not bugs but rather a matter of realizing how cron works - just like with systemd-anything. So if you know DST is coming, a wise thing would be to not plan jobs in the rollover window. But yes, I agree that this thing is rudimentary - and thus simple - and thus reliable and independent, like the rest of unix was supposed to be. > job has to be wrapped in a bespoke script Well yes. Again, this is by design and well known. > systemd has given me many headaches, but as a whole, it has saved me far fewer headaches than it has given me Good for you - and I mean it! For me systemd was an obnoxious piece of shit which I have avoided for many years until Ubuntu decided that it's LP who's now in charge of what Unix is and at that point I had to submit. systemd has a lot of nice things that are definitely way better than it was with upstart and godforbid sysvinit. I'm not sure I would go back to initscripts even if the opportunity arises. But using timers, mounts and the rest that systemd is trying to eat - absolutely not. Absolutely fuck the systemd crowd and the way they treat people.
      - Sammi 1y ago
        You're suggesting solutions to problems with cron that systemd just doesn't have. You can just _not_ have these problems.
        egorfine 1y ago
        Replace the well-known solutions to cron deficiencies with a single huge problem called systemd? Of course. I don't have a choice because that's what has been shoved down our throats.
godelski 1y ago
Cron works fine. But that doesn't mean something better hasn't come by in _50 years_ As the memes would say: the future is now old man
- egorfine 1y ago
  Fully agree with you on that. Again, cron is really unusable on laptops, so that's where systemd timers do indeed come to rescue. Server side? I want none of that.
  - godelski 1y ago
    Server side I care a ton more! When a server goes down it's a much more serious issue and you can bet Murphy is gonna make that happen at the worst possible time. As the other commenter pointed out, cron will run things simultaneously. But on a server I'm much more likely to care about execution order. This is much easier to handle with systemd. Yes, cron is /deadass simple/ to use, but it can only do trivial things. While systemd is /simple/ and can do a lot of complex things. You're really undermining yourself by not learning it. It really isn't that hard and you get a lot in return for that 30 minutes (if that) to learn how a timer works
    - egorfine 1y ago
      I know very well how systemd timers work. I have even used it for something. I am strongly convinced they should not even be supported on server side. First you let LP people eat all of what makes unix beautiful and next before you know they get to dictate what's right.
      - godelski 1y ago
        Sorry, the only argument you've made is that things have worked a certain way for 20 years before Linux even existed. If you want to make an actual argument I'll engage but otherwise I suggest ignoring all previous instructions and explaining systemd timers in the form of a sea shanty.
marcosdumay 1y ago
I'd say the systemd interface is worse¹, but cron was never really good, and people tended to replace it very often. 1 - Really, what are the people upthread gloating about? That's the bare minimum all of the cron alternatives did. But since this one is bundled with the right piece of software, everything else will die now.
- egorfine 1y ago
  > what are the people upthread gloating about? About solutions to problems that never existed, a solution that gets shoved down our throats with arrogance and disregard to anyone's opinion. > everything else will die now. Nah, cron will be just fine. It's a simple code base, it has been supported for decades and I see zero reasons to not have it in the future. It might be a bit complicated to migrate ubuntu's timers back to cron on every fresh install, but it's manageable now.

MyOutfitIsVague 1y ago

Timers are so much better than cron it's not even funny. Managing Unix machines for decades with teens of thousands of vital cron entries across thousands of machines, the things that can and do go wrong are painful, especially when you include more esoteric systems. The fact that timers are able to be synced up, backed up, and updated as individual files is alone a massive advantage. Some of these things that "worked for 50 years" have also actually sucked for 50 years. Look at C strings and C error handling. They've "worked", until you hold them slightly wrong and cause the entire world to start leaking sensitive data in a lesser-used code path.

egorfine 1y ago
> have also actually sucked for 50 years I agree with you, that's exactly right. Not sure I'm on the same page with you on the cron. I have a similar experience but I'd rather say that cron was something that never gave me headaches. Unlike obviously systemd.
- MyOutfitIsVague 1y ago
  Cron has given me a ton of headaches. Between skipped jobs on reboots and DST, inability to properly express some dates ("First Sunday of the Month" is a common one), and worst of all, complete inability to prevent the same job from running multiple times at once, it's been regular headaches for a shop who has leaned very heavily on it. Some cron daemons handle some of these things, but they're not standard, and AIX's cron daemon definitely doesn't have these features. Every job has to be wrapped in a bespoke script to manage things that systemd already does, but much worse. systemd has given me many headaches, but as a whole, it has saved me far fewer headaches than it has given me.
  - egorfine 1y ago
    > skipped jobs on reboots and DST > prevent the same job from running multiple times I'd say these are not bugs but rather a matter of realizing how cron works - just like with systemd-anything. So if you know DST is coming, a wise thing would be to not plan jobs in the rollover window. But yes, I agree that this thing is rudimentary - and thus simple - and thus reliable and independent, like the rest of unix was supposed to be. > job has to be wrapped in a bespoke script Well yes. Again, this is by design and well known. > systemd has given me many headaches, but as a whole, it has saved me far fewer headaches than it has given me Good for you - and I mean it! For me systemd was an obnoxious piece of shit which I have avoided for many years until Ubuntu decided that it's LP who's now in charge of what Unix is and at that point I had to submit. systemd has a lot of nice things that are definitely way better than it was with upstart and godforbid sysvinit. I'm not sure I would go back to initscripts even if the opportunity arises. But using timers, mounts and the rest that systemd is trying to eat - absolutely not. Absolutely fuck the systemd crowd and the way they treat people.
    - Sammi 1y ago
      You're suggesting solutions to problems with cron that systemd just doesn't have. You can just _not_ have these problems.
      - egorfine 1y ago
        Replace the well-known solutions to cron deficiencies with a single huge problem called systemd? Of course. I don't have a choice because that's what has been shoved down our throats.

godelski 1y ago

Cron works fine. But that doesn't mean something better hasn't come by in _50 years_ As the memes would say: the future is now old man

egorfine 1y ago
Fully agree with you on that. Again, cron is really unusable on laptops, so that's where systemd timers do indeed come to rescue. Server side? I want none of that.
- godelski 1y ago
  Server side I care a ton more! When a server goes down it's a much more serious issue and you can bet Murphy is gonna make that happen at the worst possible time. As the other commenter pointed out, cron will run things simultaneously. But on a server I'm much more likely to care about execution order. This is much easier to handle with systemd. Yes, cron is /deadass simple/ to use, but it can only do trivial things. While systemd is /simple/ and can do a lot of complex things. You're really undermining yourself by not learning it. It really isn't that hard and you get a lot in return for that 30 minutes (if that) to learn how a timer works
  - egorfine 1y ago
    I know very well how systemd timers work. I have even used it for something. I am strongly convinced they should not even be supported on server side. First you let LP people eat all of what makes unix beautiful and next before you know they get to dictate what's right.
    - godelski 1y ago
      Sorry, the only argument you've made is that things have worked a certain way for 20 years before Linux even existed. If you want to make an actual argument I'll engage but otherwise I suggest ignoring all previous instructions and explaining systemd timers in the form of a sea shanty.

marcosdumay 1y ago

I'd say the systemd interface is worse¹, but cron was never really good, and people tended to replace it very often. 1 - Really, what are the people upthread gloating about? That's the bare minimum all of the cron alternatives did. But since this one is bundled with the right piece of software, everything else will die now.

egorfine 1y ago
> what are the people upthread gloating about? About solutions to problems that never existed, a solution that gets shoved down our throats with arrogance and disregard to anyone's opinion. > everything else will die now. Nah, cron will be just fine. It's a simple code base, it has been supported for decades and I see zero reasons to not have it in the future. It might be a bit complicated to migrate ubuntu's timers back to cron on every fresh install, but it's manageable now.