| |||||||||||||
|
| |||||||||||||
upstart as cron replacementupstart as cron replacementPosted Aug 31, 2006 19:41 UTC (Thu) by vmole (guest, #111)In reply to: upstart as cron replacement by smurf Parent article: What's happening at Ubuntu: from X.org updates to upstart
You've given two good reasons why cron needs to be replaced. I'm still not convinced that it makes sense to combine it with init. Yes, init is conceptually the right place to do stuff on startup and shutdown, and providing users a good way to do this would be good. But for periodic jobs, I don't see why init is a better fit. Now I'll actually go read about Upstart and learn why I'm wrong :-)
(Log in to post comments)
upstart as cron replacement Posted Aug 31, 2006 21:05 UTC (Thu) by smurf (subscriber, #17840) [Link] init has the unique property that it gets SIGCHLD for all processes which happen to die after their parent. Thus it is able to keep track of exactly when a job is finished, even if that job daemonizes or forks itself. (For the most part.)
This means that you don't have to futz around with either putting your jobs into the background (standard This also applies to cron jobs and the locking one might want to apply to their execution.
I don't know if you have looked at the cron code. The thing is ugly, and not just because 19-year-old code shows its age. The twenty In principle, hacking support for the features Upstart offers into cron -- it could monitor the events Upstart generates, and extending the crontab syntax doesn't look to difficult -- is certainly possible, but (not only IMHO) a rewrite would be a lot cleaner. The task is too important to do it as a dirty hack. And if you rewrite it anyway, you might as well put the task into init where it can profit from init's aforementioned special status.
upstart as cron replacement Posted Aug 31, 2006 22:48 UTC (Thu) by vmole (guest, #111) [Link] I don't know if you have looked at the cron code. The thing is ugly, and not just because 19-year-old code shows its age. Have I looked at the cron code? Heh. Far too long, far too much. I was the Debian cron maintainer for ~10 years (Javier Fernandez-Sanguino took over last year, bless his soul). You don't have to convince me the code is not pretty. However, a package maintainer can only do so much before the codebase is no longer compatible with patches from others. The twenty #ifdef DEBIANs it has acquired don't exactly help either; the Debian patch, when you run it through wc -l, is larger than the original sources. Well, I though keeping the Debian specific functionality (as opposed to general fixes) seperated was worth the small amount of visual noise; opinions may vary. If I'd realized how big it was going to grow, maybe I would have chosen differently. Regarding the patch size, you can't compare the linecount to the original - your counting both lines removed and lines added (one each for changed lines), plus all the new stuff in the ./debian directory. And there is *a lot* of functionality in the diff: support for cron.d, some support for DST and clock changes, big security fixes. Defensiveness aside, I certainly wouldn't argue that you should hack Vixie cron - it needs to be re-written from the ground up, designed around whatever features are desired. I'm just not convinced that combining init, cron/at/etc., and inetd is the correct choice, despite (IMO) superficial simularities. In particular, I think maintaining appropriate security domains may be more complicated than one would like.
upstart as cron replacement Posted Aug 31, 2006 23:13 UTC (Thu) by smurf (subscriber, #17840) [Link] I'm just not convinced that combining init, cron/at/etc., and inetd is the correct choice, despite (IMO) superficial simularities. In particular, I think maintaining appropriate security domains may be more complicated than one would like.
I'm not entirely sure about that myself; certainly the requirements for a safe Personally, I wouldn't be entirely happy writing something that complex, but that's simply because I do like to run my code under
upstart as cron replacement Posted Sep 3, 2006 8:20 UTC (Sun) by bockman (guest, #3650) [Link] init has the unique property that it gets SIGCHLD for all processes which happen to die after their parent. Thus it is able to keep track of exactly when a job is finished, even if that job daemonizes or forks itself. (For the most part.) It could export this feature: when an orphan child dies, upstart could notify other interested processes of the event. You would need a registration API and a way to transmit the information. Then an independent cron replacement could use this service. Maybe. Just an idea. :-)
Ciao
upstart as cron replacement Posted Sep 12, 2006 12:02 UTC (Tue) by robbe (subscriber, #16131) [Link] > init has the unique property that it gets SIGCHLD for all processes which> happen to die after their parent. Thus it is able to keep track of exactly > when a job is finished, even if that job daemonizes or forks itself. (For > the most part.)
Let's say init starts a daemon (e.g. apache as pid 100) directly and it daemonizes itself (i.e. forks to pid 105, and pid 100 terminates). The init will then get a SIGCHLD from pid 100 and supposes the daemon job as "finished". It doesn't know that pid 100 and pid 105 are connected. If the daemon exits or crashes later init will notice that pid 105 has terminated, but does not connect this fact with the apache job it started sometime in the past. (One can usually suppress daemonization via a commandline argument, though.)
Right now most daemons are started via scripts that setup the environment etc. If init runs this script it knows its pid and when it finishes. Again, it does not know the pid of the real worker process that the script forks off.
Some of your other comments to this article rely on part on this assumption which I argue to be wrong...
upstart as cron replacement Posted Sep 12, 2006 12:28 UTC (Tue) by smurf (subscriber, #17840) [Link] It's true that per se, init doesn't associate job 105 with the process 100 that it started. But that is easily fixed.
The simplest way is to actually tell
|
|
||||||||||||