6 ms·

Yes, I should clarify Cron doesn't understand system load Cron doesn't understand suspend/resume Cron doesn't understand anything Disk intensive daily

by feld 11y ago

Yes, I should clarify Cron doesn't understand system load Cron doesn't understand suspend/resume Cron doesn't understand *anything* Disk intensive daily jobs shouldn't run if the system is being crushed. I don't want to update my locate database during a backup or during a zpool resilver. If I pause/suspend a {VM, server, laptop} and wake it, jobs are missed ... because it's not time to run them. What if I'm live migrating a VM and there's an important job that needs to run during the time it momentarily freezes the VM for migration? VM resumes on new cluster, job wasn't run. Sure if you're doing this once by hand you can be smart about making sure the timing of migration is safe and the job actually runs. But what if you're running thousands of servers? Ok, so now we throw a ton of code at the wall customized to our environment and hope we don't miss any edge cases. Or we can stop reinventing the wheel and use a job scheduling system that solves this problem. Have you had the fun of cron jobs getting stuck and seeing them just endlessly build up, each one starting the job over from scratch, I/O grinding to a halt as the server gasps for breath under their weight? Alright, lesson learned, customers were angry, now we know we should wrap the job with a lockfile (and hope it's a proper BSD lockf(1) which guarantees atomicity) ... or you can have an intelligent scheduling system that knows not to do such a thing. The possibilities are endless when you feed intelligence into a cron replacement.

dijit 11y ago
there is a lead programmer where I work, a fiercely intelligent man.. the kind of person you want to be an architect of a project.. the kind of man that invents solid things _ALWAYS_ says. "Do a thing, do it well, do only that thing; if you build things stupid and predictable they can be robust and reliable" He's a C++ Developer working on windows. Not some GNU nut. intelligence is fine, but it's hard to code, does unpredictable things and becomes a burden. also, you can turn Cron off, it's not like it's a required system, it doesn't even come enabled by default for desktop distros (such as would be used on a laptop)
- pmoriarty 11y ago
  "He's a C++ Developer working on windows. Not some GNU nut." An otherwise excellent comment ruined with a smear.
  - dijit 11y ago
    I mentioned it because I am a GNU nut, not intended as a smear. But people like to shut down your "argument" when you start saying things that sound like the unix philosophy.
simoncion 11y ago
> Disk intensive daily jobs shouldn't run if the system is being crushed. ionice(1) works really well on Linux. > Have you had the fun of cron jobs getting stuck and seeing them just endlessly build up... It sounds like this would be fairly easy to fix. Either set a timeout for each cron job, or make a mark when each job completes and don't start a second copy of that job if the mark is not found. Regardless, I don't see how these are reasons that cron needs to die. They are decent reasons for improving cron. ;)
- click170 11y ago
  I think there's an argument to be made that these things dont belong in cron, they belong in logic that lives elsewhere. Do one thing and do it well.
  - simoncion 11y ago
    > Do one thing and do it well. The trick is determining what thing you're going to do. I think it's perfectly reasonable for a job scheduler to have the ability to terminate jobs that run for too long and to ensure that no more than N copies of a given job are running simultaneously. This sort of thing also satisfies the DRY principle. :)
  - feld 11y ago
    > Do one thing and do it well. People really like to parrot this statement. Nobody is going to make it do "more" than a scheduling tool. It's not going to become a volume manager or start steering your clock... Why aren't you angry about these redundancies: * sort's -u flag when there's uniq ? * grep's ability to search recursively when there's find ? * grep's existence when there's ed ? * cron's existence when there's at ? * cat's existence when there's < ? We could play this game all day.
    - dijit 11y ago
      many of those things dont actually do the same thing. at runs a scheduled job once and then terminates, cron runs scheduled jobs repeatedly. ed/sed are powerful languages that are used for 'changing' data, not searching it.. it _can_ be used to search but it's very heavy for the task. grep also searches content of files recursively, where as find does not, having find do it means forking the process and being very heavy also. cat and < are different in that one is a shell builtin and is used to.. concatonate files.. which the shell builtins do not do... ofc many people "use it wrong" but that's neither here nor there in this discussion. https://en.wikipedia.org/wiki/Cat_(Unix)#Useless_use_of_cat https://en.wikipedia.org/wiki/Cat_(Unix)#Useless_use_of_cat

Yes, I should clarify Cron doesn't understand system load Cron doesn't understand suspend/resume Cron doesn't understand *anything* Disk intensive daily

by feld 11y ago

dijit 11y ago

there is a lead programmer where I work, a fiercely intelligent man.. the kind of person you want to be an architect of a project.. the kind of man that invents solid things _ALWAYS_ says. "Do a thing, do it well, do only that thing; if you build things stupid and predictable they can be robust and reliable" He's a C++ Developer working on windows. Not some GNU nut. intelligence is fine, but it's hard to code, does unpredictable things and becomes a burden. also, you can turn Cron off, it's not like it's a required system, it doesn't even come enabled by default for desktop distros (such as would be used on a laptop)

pmoriarty 11y ago
"He's a C++ Developer working on windows. Not some GNU nut." An otherwise excellent comment ruined with a smear.
- dijit 11y ago
  I mentioned it because I am a GNU nut, not intended as a smear. But people like to shut down your "argument" when you start saying things that sound like the unix philosophy.

simoncion 11y ago

> Disk intensive daily jobs shouldn't run if the system is being crushed. ionice(1) works really well on Linux. > Have you had the fun of cron jobs getting stuck and seeing them just endlessly build up... It sounds like this would be fairly easy to fix. Either set a timeout for each cron job, or make a mark when each job completes and don't start a second copy of that job if the mark is not found. Regardless, I don't see how these are reasons that cron needs to die. They are decent reasons for improving cron. ;)

click170 11y ago
I think there's an argument to be made that these things dont belong in cron, they belong in logic that lives elsewhere. Do one thing and do it well.
- simoncion 11y ago
  > Do one thing and do it well. The trick is determining what thing you're going to do. I think it's perfectly reasonable for a job scheduler to have the ability to terminate jobs that run for too long and to ensure that no more than N copies of a given job are running simultaneously. This sort of thing also satisfies the DRY principle. :)
- feld 11y ago
  > Do one thing and do it well. People really like to parrot this statement. Nobody is going to make it do "more" than a scheduling tool. It's not going to become a volume manager or start steering your clock... Why aren't you angry about these redundancies: * sort's -u flag when there's uniq ? * grep's ability to search recursively when there's find ? * grep's existence when there's ed ? * cron's existence when there's at ? * cat's existence when there's < ? We could play this game all day.
  - dijit 11y ago
    many of those things dont actually do the same thing. at runs a scheduled job once and then terminates, cron runs scheduled jobs repeatedly. ed/sed are powerful languages that are used for 'changing' data, not searching it.. it _can_ be used to search but it's very heavy for the task. grep also searches content of files recursively, where as find does not, having find do it means forking the process and being very heavy also. cat and < are different in that one is a shell builtin and is used to.. concatonate files.. which the shell builtins do not do... ofc many people "use it wrong" but that's neither here nor there in this discussion. https://en.wikipedia.org/wiki/Cat_(Unix)#Useless_use_of_cat https://en.wikipedia.org/wiki/Cat_(Unix)#Useless_use_of_cat