IRC meeting
Daniel L. Miller
dmiller at amfes.com
Wed Nov 28 21:43:22 GMT 2007
Rob Ubuntu Linux wrote:
> On Nov 27, 2007 3:10 AM, Shawn Rutledge <shawn.t.rutledge at gmail.com> wrote:
>
>> On Nov 26, 2007 4:31 PM, Scott James Remnant <scott at netsplit.com> wrote:
>>
>>> On Mon, 2007-11-26 at 13:40 -0700, Shawn Rutledge wrote:
>>>
>>>
>>>> On Nov 26, 2007 2:01 AM, Scott James Remnant <scott at netsplit.com> 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
More information about the upstart-devel
mailing list