[sf-lug] init, upstart, and all that jazz

[Michael Paoli]

Well, just my opinion(s), *but*, ...

While upstart may be usefully trying to solve a particular problem or
set of problems, I think to a fair extent, it goes about it the wrong
way.  First of all, since the beginning of time, ... well, the Unix
epoch, ... well, pretty close to then, anyway, Unix et. seq. in most
normal circumstances, the first "real" PID the kernel launches is init,
as PID 1.  The init program then reads /etc/inittab - which also has and
has had a rather stable well documented format, again, since (nearly)
the beginning of (Unix) time.  The init program has various run levels,
and also pseudo run levels, and can also take some other actions (e.g.
rereading /etc/inittab).  All this stuff about hot pluggable, and other
problems that other Unix tries to solve (e.g. monitoring a service and
restarting it if it fails), doesn't need to be solved in some radically
different way (in fact init itself can monitor and restart a process
when it exits - e.g. this is typically done for serial and console login
devices, among others).  Getting rid of /etc/inittab or init - at least
without having *darn good reason* is generally a bad idea - notably
violating the Principle of Least Surprise, among other issues.

SysV type init/rc is rather commonly used among Unix etc., but it's not
the only way.  The relatively classic SysV initialization has as one
key drawback, that it doesn't deal particularly well with quite long
running startup tasks ... but not only is that generally dealt with
fairly easily via backgrounding, but many Unix etc. flavors have
extended their initialization setup a bit so such is easily dealt with
in a quite "standard" (at least within a flavor/version) way (such as
HP-UX has done).

Another drawback of SysV type init/rc is that it's a mostly synchronous
procedure - tasks run in order to completion before next task is
started.  That's often slower approach than what's needed/desired.
Initialization isn't really just a strict list of things to be started
- it's more of a dependency tree.  There are alternative systems that
do initialization based upon dependency specifications.  There's
nothing about taking such an alternative approach that conflicts with
using init and /etc/inittab.  Again, init kicks (or should kick) things
off via /etc/inittab contents, ... and one can get rather to quite
creative from there as far as exactly how things are done.

Hotplug is an issue to yet be (fully) solved, but there's no reason that
requires tossing out init and/or /etc/inittab ... or even necessarily
tossing out (or modifying) SysV type init/rc (though one might want to
modify or replace SysV type init/rc for other reasons) to solve dealing
with hotplug.  There are already other schemes that deal with hotplug -
and that don't conflict with init, /etc/inittab, or even SysV type
init/rc.  Perhaps some of them could yet be done better, and/or more
seamlessly interoperate with init, /etc/inittab, and even SysV type
init/rc - at least where there is likely to be some overlap ... but
other than that, no need to toss out init, /etc/inittab, or SysV type
init/rc on account of hotplug.

Another area is "services".  The typical basic init, /etc/inittab, and
(most typically) SysV init/rc typically starts processes up (and also
often handles shutting them down), but otherwise doesn't pay much
attention to them.  Such isn't very ideal for wanting to have more
robust services - i.e. services that will restart if the PID dies, or be
restarted if the PID is still there but the service has become
unresponsive.  Here, again, solving that doesn't conflict with init,
/etc/inittab, and SysV type init/rc or the like.  This is also a case
where I think Sun took the wrong approach.  This is easily addressed by
simple addition of a layer.  Rather than the init (typically rc) script
simply launching the PID and forgetting about it, one uses a layer in
between.  Something that will *manage* the service - e.g. launch it, and
also monitor and restart it when appropriate - and continue to do so
until it's told to do otherwise.  Quite straight forward solution, and
doesn't require tossing out one's existing init system.  It also can be
quite selectively applied - e.g. for some initialization tasks which are
much simpler, they may not at all be services one wants to bring up and
monitor, but simply do some simple task (e.g. truncate the utmp file),
and be done with it - no need for some snazzy middle layer in the many
much simpler cases.

Oh, ... and for upstart (and xen!), etc.  Yes, Open Source is great.
But it's no excuse for lack of sufficiently good and sufficiently
complete documentation.