IRC meeting

[Daniel L. Miller]

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