initialization vs supervision

From: Wayne Marshall <wcm_at_b0llix.net>
Date: Wed, 23 Jul 2014 12:16:24 -0700

Initialization vs Supervision

In recent discussions on this forum and elsewhere, there is
a tendency to conflate start-up initialization with service
supervision. The historical basis for this tendency is found
in various versions of /sbin/init that do in fact coalesce some
aspects of initialization with some elements of "supervision",
and to varying degrees.

But before continuing discussions of yet more "alternatives"
to init(8) and start-up architectures, it may be worthwhile
to actually review some of the profound differences between
initialization and supervision, and to ponder if it is at all
sensible to continue stuffing them into the same envelope.

Because in fact the two functions are quite different. Almost
diametrically so. Below is a brief discussion of some of the more
significant differences between them in terms of intended purpose,
troubleshooting, and portability.


intended purpose
-------- -------
* initialization: run one-time processes at system startup
* supervision: run persistent processes for system duration

The purpose of start-up initialization (should be) fairly simple
and straightforward, mount some local disk/partitions, maybe
initialize some local network, and otherwise whatever small tasks
are required to bring the system up to a state of readiness for work.
Then start a service supervisor, and otherwise stay out of the
way until system shutdown, when init may do some final clean-up
and safe unmounting prior to powering off.

In comparison, the supervisor takes care of providing for the
consistent and stable management of persistent processes, those
long-running services that are expected to run reliably for the
duration of the system uptime.

The functions of system initialization are often performed
sequentially, whereas process supervision may generally be performed
asynchronously and in parallel.


troubleshooting
---------------
* initializaion: hard
* supervision: easy

When init goes awry, the system panics and/or reboots and it
can be extremely difficult to figure out what has gone amiss.
It is especially problematic to expect an end-user to deal with
init(8) problems. These should all be sorted out and rock-solid
prior to delivery from the system integrator.

In comparison, when a particular service or even the supervisor has
some problem, it is usually a straightforward matter to diagnose
and correct, and does not generally take down the whole system in
the process. A service management framework can be sufficiently
"user-friendly" to allow any reasonably competent end-user to
manage their systems properly and portably.


portability
-----------
* initialization: system-specific
* supervision: system-agnostic

By its very nature, system initialization tends to be highly
system-specific. Start-up initializations are generally
configured relative to a particular set of hardware, software,
operating system, and even particular distribution. As anyone
who has ever tried will know, it is extremely difficult to come
up with a plug-and-play design of portable system initialization,
that works and works reliably across multiple platforms.

In comparison, there exist service supervisors that are perfectly
system-agnostic and capable of operating identically among any modern
un!x environment.


Anyway, these are just a few notes that may help clarify further
discussions about future directions for system initialization and
service supervision. In the best of un!x traditions, a stronger
system may in fact be one that recognizes the fundamental
differences between the two functions, and provides purpose-specific
solutions for each of them.

Wayne
Received on Wed Jul 23 2014 - 19:16:24 UTC