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