| |||||||||||||
|
| |||||||||||||
upstart as cron replacementupstart as cron replacementPosted Aug 31, 2006 20:50 UTC (Thu) by kh (subscriber, #19413)In reply to: upstart as cron replacement by smurf Parent article: What's happening at Ubuntu: from X.org updates to upstart
it doesn't know not to run my database sync job until *after* mysql has started up This seems to me to be a perfect example of what not to put in a cron replacement daemon (because of feature creep). Currently, I believe you could have the database sync job test if mysql is running (and either start it or exit on error status if not - but I at least would want to control that in my script, not have cron decide). I don't want a super daemon constantly monitoring all the other daemons and deciding what cron jobs to run and which not to.
(Log in to post comments)
upstart as cron replacement Posted Aug 31, 2006 22:59 UTC (Thu) by smurf (subscriber, #17840) [Link] Currently, I believe you could have the database sync job test if mysql is running (and either start it or exit on error status if not - but I at least would want to control that in my script, not have cron decide). I don't want a super daemon constantly monitoring all the other daemons and deciding what cron jobs to run and which not to.?? The decision which jobs to run would lie with the author of the job, not with upstart: you decide on the rules for your script, not cron or anybody else.
Besides: What do you mean by "constantly monitoring"? If it's an init replacement, it doesn't need to monitor anything, because it knows: it gets the information from the kernel for free, no need to poll anything, much less
The idea behind integrating all of this in some way is that you can just add the "requires foobar" idea to your cron or at job (remember this will be started after Edgy, so nobody has any concrete ideas about syntax yet).
Joe can't do the former himself, he doesn't have the privileges; the latter is a waste of resources -- if you know beforehand that
upstart as cron replacement Posted Sep 1, 2006 1:27 UTC (Fri) by kh (subscriber, #19413) [Link] ?? The decision which jobs to run would lie with the author of the job, not with upstart: you decide on the rules for your script, not cron or anybody else. You did not understand what I was trying to say, I am not comfortable with the idea of moving the logic for tests (such as "is the database server running?") from the sync (or whatever) script, where is currently resides, to the cron replacement (i.e. the update config (crontab?) file). And I do not understand how it is possible to do so with a terse language for the config file, and yet have update be aware of every different possible daemon, their states, the system states, & etc. That seems like a LOT of new features for cron.
No service-specific tests Posted Sep 1, 2006 7:28 UTC (Fri) by smurf (subscriber, #17840) [Link] The test upstart will do, using the mysql example, is not "can I connect to port 3306 and get a sensible reply", but "I have forked off/usr/sbin/mysqld and it hasn't died yet".
Testing for actual services isn't upstart's job; I agree that that makes no sense whatsoever. NB: I don't know how upstart is going to decide that a service has finished starting up. I assume it'll be something along the lines of "the startup script has exited but some of its children are still running" by default, but I haven't checked.
|
|
||||||||||||