IRC meeting

[Rob Ubuntu Linux]

On Nov 28, 2007 9:43 PM, Daniel L. Miller <dmiller at amfes.com> wrote:

> 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.

There's still things like "nohup long-runner &".  Noone (yet?) has
suggested that shell's fire off events and request a service, rather
than directly make system call, so it's actually not all background
processes, and daemons.

That is interesting way of organising stuff, and it's another way of
managing a cron/atd (don't forget batch(1) if you do it) package.

Currently cron figures out when the next job to start is, sleeps until
then, unless it's woken up by a config file change notification, when
it recalculates it's alarm call.  So again like Sys V init(8) it has
some configuration, then responds to events which are signals, for
instance when a child is done.  The at & batch queues, run a number of
one off jobs simulataneously (perhaps only if the load average is low
enough).

This stuff is in Posix :

at - http://www.opengroup.org/onlinepubs/009695399/utilities/at.html
batch - http://www.opengroup.org/onlinepubs/009695399/utilities/batch.html
crontab - http://www.opengroup.org/onlinepubs/009695399/utilities/crontab.html

And there's "Batch Environment Services and Utilities"  NQS based
http://www.opengroup.org/onlinepubs/009695399/xrat/xcu_chap03.html

Alot of which is stuff done for users, and access controls mean
security; which is making the "simple event driven init" much less
simple.  In a way if you have a daemon doing IPC, then there's less
reason to communicate via changes in the filesystem, why not use a
protocol to return info on demand?  Job specs would still have to be
on disk, to persist across re-boots (or the bad RAM that causes
Upstart cron to crash.

What are the advantages of re-implementing the batch stuff?  What is
done badly at moment?

The core idea of Upstart, that I like is the event driven dynamism,
making intelligent response to hotplug events and (I'll use adjective)
"soft" configuration changes (meaning ones at behest of a User
fiddling with buttons in an applet) ie. Bring the network interface up
now!

It could help packages implementing services, find out and communicate
with other services, and allow query and setup of values.  That could
clean up the awful attempts made by packages to configure other ones
(which change under them) and may be re-implemented in future, in a
different way, which then requires a whole slew of system changes, to
support the new package.


If a hotplug event, or soft configuration change ie whim of user,
involves crontab, at or batch, or the NQS style services, why can't
some task, have the event and info punted to them, by Upstart, and
then let it handle the configuration issues?

May be there's a big advantage there that I am missing, that's not
just down to some similarities of parts of the code.