5 ms·

This is exactly the counter-argument that Jordan & co constantly have to battle. "I've never had this problem!" Networking: not what I said Cron: Cron is ter

by feld 11y ago

This is exactly the counter-argument that Jordan & co constantly have to battle. "I've never had this problem!" Networking: not what I said Cron: Cron is terrible. Paul Vixie says so himself. Get over it. (everyone, not directed at you) Config files: you're inferring the wrong thing HUP: I shouldn't have to HUP a process to make it learn new things. It should be able to learn them automatically by listening for an event. Please, take a listen of exactly the scenarios Jordan lays out in the latest BSDNow podcast. It makes sense. If we want to be able to build really cool reliable non-kludgey things in the future we need these kinds of features. If your Unix is a server that never moves or changes this is going to sound uninteresting and overkill. But I want the future to allow us to be able to do really awesome stuff. I envision being able to live migrate servers from my basement to Amazon to Vultr to Digital Ocean and not have a single process puke because of changes (network interfaces, IPs, hostnames, etc)

lvh 11y ago
Parent was asking for (among other things) reasons why cron needs to die; saying Vixie ipse dixit is true, but not a technical argument. Notably, it doesn't help the reader understand what the replacement ought to look like.
- 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.
- JdeBP 11y ago
  > Vixie ipse dixit is true, but not a technical argument. It's also rather presuming that Vixie cron is the only cron, something that hasn't been true for ... ahem! ... a little while now. Back at the turn of the century, a bloke named Paul Jarc looked into how one could do cron the daemontools way. What he came up with was called runwhen. You can still find his WWW page on the subject. * http://code.dogmap.org/runwhen/ http://code.dogmap.org/runwhen/ I incorporated some of the ideas into the (32-bit) OS/2 Command Line Utilities, albeit heavily modified to address an operating system that most definitely did not do chain loading. * http://homepage.ntlworld.com./jonathan.deboynepollard/Softwares/clu.html#runwhen http://homepage.ntlworld.com./jonathan.deboynepollard/Softwa... There are several things to learn from this. First, the world is not as rigid as some would have you believe. There's been a lot of work on service and system management, cron alternatives, and other stuff over the years. For a less radical cron than runwhen, witness Bruce Guenter's bcron. (The nosh package has a service bundle for bcron, by the way.) * http://untroubled.org/bcron/ http://untroubled.org/bcron/ * http://blog.darknedgy.net/technology/2015/09/05/0/ http://blog.darknedgy.net/technology/2015/09/05/0/ Second, what might be true about old Vixie cron specifically isn't gospel for the entire world. It's interesting to observe, as I have mentioned before, how much influence the daemontools family has had over the past decade and a half. Looking at cronie, to pick an example, one can see it nowadays is yet another member of the club of programs sporting a "don't do all that bogus daemonization stuff" option, -n in this case. GNU cron (a.k.a. Mellor cron) actually does not "daemonize" by default, and one has to explicitly choose that with a -d option. To look at old Vixie cron, one might come to the erroneous conclusion that cron always and unavoidably "daemonizes", something that was indeed a problem for daemontools users in the late 1990s. But this isn't true by a long chalk today.
pdkl95 11y ago
> Cron is terrible. Paul Vixie says so himself. Get over it. "cron" does not[1] necessarily imply vixie-cron. A variety of implementations are available that have different feature sets. What exactly do you not like about cron the concept, and how are you running periodic events without > HUP ... listening for an event HUP is an "event". What is this "event" you want to listen for that requires junking HUP support? A new event type that tells the daemon the same information is just as kludgey as sending SIGHUP while adding unnecessary complexity. You can listen for an inotify event (or similar) on relevant file handles if you want, but that isn't applicable in all cases. If your complaint is that some daemon doesn't support something like inotify, file a feature request or send patches. HUP has the advantage that it is well-known, and you probably probably still want a way to force a daemon to re-read it's configuration even if you are already detecting changes with inotify/whatever. [1] I use fcorn ( http://fcron.free.fr/ http://fcron.free.fr/ )
- JdeBP 11y ago
  The nosh package gained a service bundle for fcron in version 1.20, back in September. As you can see, it uses the --foreground and --nosyslog options. Thank you for those M. Godouet.

by feld 11y ago

lvh 11y ago

Parent was asking for (among other things) reasons why cron needs to die; saying Vixie ipse dixit is true, but not a technical argument. Notably, it doesn't help the reader understand what the replacement ought to look like.

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.
JdeBP 11y ago
> Vixie ipse dixit is true, but not a technical argument. It's also rather presuming that Vixie cron is the only cron, something that hasn't been true for ... ahem! ... a little while now. Back at the turn of the century, a bloke named Paul Jarc looked into how one could do cron the daemontools way. What he came up with was called runwhen. You can still find his WWW page on the subject. * http://code.dogmap.org/runwhen/ http://code.dogmap.org/runwhen/ I incorporated some of the ideas into the (32-bit) OS/2 Command Line Utilities, albeit heavily modified to address an operating system that most definitely did not do chain loading. * http://homepage.ntlworld.com./jonathan.deboynepollard/Softwares/clu.html#runwhen http://homepage.ntlworld.com./jonathan.deboynepollard/Softwa... There are several things to learn from this. First, the world is not as rigid as some would have you believe. There's been a lot of work on service and system management, cron alternatives, and other stuff over the years. For a less radical cron than runwhen, witness Bruce Guenter's bcron. (The nosh package has a service bundle for bcron, by the way.) * http://untroubled.org/bcron/ http://untroubled.org/bcron/ * http://blog.darknedgy.net/technology/2015/09/05/0/ http://blog.darknedgy.net/technology/2015/09/05/0/ Second, what might be true about old Vixie cron specifically isn't gospel for the entire world. It's interesting to observe, as I have mentioned before, how much influence the daemontools family has had over the past decade and a half. Looking at cronie, to pick an example, one can see it nowadays is yet another member of the club of programs sporting a "don't do all that bogus daemonization stuff" option, -n in this case. GNU cron (a.k.a. Mellor cron) actually does not "daemonize" by default, and one has to explicitly choose that with a -d option. To look at old Vixie cron, one might come to the erroneous conclusion that cron always and unavoidably "daemonizes", something that was indeed a problem for daemontools users in the late 1990s. But this isn't true by a long chalk today.

pdkl95 11y ago

> Cron is terrible. Paul Vixie says so himself. Get over it. "cron" does not[1] necessarily imply vixie-cron. A variety of implementations are available that have different feature sets. What exactly do you not like about cron the concept, and how are you running periodic events without > HUP ... listening for an event HUP is an "event". What is this "event" you want to listen for that requires junking HUP support? A new event type that tells the daemon the same information is just as kludgey as sending SIGHUP while adding unnecessary complexity. You can listen for an inotify event (or similar) on relevant file handles if you want, but that isn't applicable in all cases. If your complaint is that some daemon doesn't support something like inotify, file a feature request or send patches. HUP has the advantage that it is well-known, and you probably probably still want a way to force a daemon to re-read it's configuration even if you are already detecting changes with inotify/whatever. [1] I use fcorn ( http://fcron.free.fr/ http://fcron.free.fr/ )

JdeBP 11y ago
The nosh package gained a service bundle for fcron in version 1.20, back in September. As you can see, it uses the --foreground and --nosyslog options. Thank you for those M. Godouet.