Rob Ubuntu Linux wrote: > On Nov 27, 2007 3:10 AM, Shawn Rutledge <[EMAIL PROTECTED]> wrote: > >> On Nov 26, 2007 4:31 PM, Scott James Remnant <[EMAIL PROTECTED]> wrote: >> >>> On Mon, 2007-11-26 at 13:40 -0700, Shawn Rutledge wrote: >>> >>> >>>> On Nov 26, 2007 2:01 AM, Scott James Remnant <[EMAIL PROTECTED]> wrote: >>>> >>> All init needs to do is spawn processes, and reap them when they die; >>> with some handling for determining when it needs to do the former and >>> working out what to do about the latter. >>> >> Well at first glance I was inclined to think that when upstart aims to >> replace crond and atd, those might be good examples of functionality >> that could be plugins. Then again, the whole point is that events >> trigger processes to be launched, and the state of the system clock >> can be just another kind of event, so making upstart have cron >> functionality is pretty much aligned with its usual behavior. >> > > Given the case made elsewhere, for small simple code, I'm wondering > what you really gain by bringing cron & atd into 1 process. > Currently there's a choice of cron packages to which may suit some > deployments better than others. Making a monolithic program in 1 > package, will mean choosing the right behaviour, which then may become > a limititation, should say the machine be part of some cluster, with > distributed batch processing (or the unfeasible complication of > implementing all possible behaviours in a critical system daemon). > A thought - if the scheduled execution implementation (cron/atd replacement) is basically an "emit timecode" event, where "timecode" is one of Month/Day/DayOfWeek/Hour/Minute/etc., then all "background" processes would be started - and stored - in the same location. While it might be beneficial to group events in folders by category, e.g. "System Processes", "Hourly Events", etc. these could also be done via symlinks - even symlinks back to existing cron jobs (though doing so would then require a cron-to-upstart preprocessor).
The result leads to a potential paradigm change for overall program control. Instead of performing a "/etc/init.d/foo start", or even a "/usr/bin/bar start" - by having the package install programs modified to add the appropriate symlinks ALL our programs would be started via "emit myprogram start". So all daemonization - or other background processes - are controlled via a single consistent interface. Or am I just sleep deprived? -- Daniel -- upstart-devel mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/upstart-devel
