Re: design of process #1 programs
The Wanderer:
At a glance at the sysvinit source, it doesn't look to me like
/sbin/init itself does service management, in the "starting, stopping
and monitoring services" form; at most, it seems to handle some subset
of the "monitoring" part, in the form of noticing when something has
died abnormally. (Which goes well beyond just services, when necessary.)
I see that Russ Allbery has already addressed the error here.
The Wanderer:
If that's correct, and if the systemd PID 1 binary handles service
management, then that's something it's doing which the init daemon
itself has not traditionally done. Which doesn't automatically mean that
it shouldn't, but which does seem to eliminate the argument that it
"only does what [the init daemon is] supposed to do".
Notions of what process #1 is "supposed" to do are by their natures
subjective. A meaningful objective design criterion is what process #1
at minimum _must_ do. The kernel imposes several requirements on it.
And there are always some operating-system-specific things of various
kinds that it has to do. When it comes to what process #1 has
_traditionally_ done, then we are not at that minimum and never really
have been.
Sadly, tradition usually isn't what people say it to be, moreover. Too
many people (a) think that the world begins and ends with Linux, (b)
have little knowledge of history, or (c) get rc and init mixed up. For
example: System 5 init and System 5 rc date to System 5, which was
almost as far after the first UNIX as we are now (say) after the first
version of Linux-Mandrake. 1st Edition UNIX only had init. It did not
have rc. The 1st Edition assembly language init spawned and respawned
12 getty processes, mounted 3 hardwired filesystems, and directly ran a
program from the home directory of a user named "mel". The getty table
was directly in the program image.
The Wanderer:
Looking at the sysvinit source for this, and thinking about the
differences in relation to systemd, has led me to come up with some
ideas in regard to possible init-system-et-al. design which I think may
be interesting enough to be worth pursuing or at least discussing.
Really, if that's all that you've read, you have a lot more to read.
System V init/rc and systemd don't even cover half of what there is to
know. There's been a lot of work in the area of init system design (for
Linux and the BSDs) that has happened in the past two decades alone.
All sorts of engineering decisions have been discussed, made, designed,
and implemented.
These include: a more human-readable configuration file for init
(http://troglobit.com/finit.html); filesystem-is-the-database
configuration, small memory footprints, and start/stop dependencies
(http://www.fefe.de/minit/); dependencies, named targets, multiple
configuration files, and a more flexible configuration syntax with a
whole load more settings for child processes (http://initng.org/);
pushing all of the service management out including even the getty
spawning and zombie reaping, and just handling operating-system-specific
"API" devices/symlinks/directories and system events
(http://homepage.ntlworld.com./jonathan.deboynepollard/Softwares/nosh.html);
and the just spawn four shell scripts approach (http://smarden.org/runit/).
About 10 years ago, there was discussion amongst daemontools users and
others of using "svscan" as process #1, which led to projects like Paul
Jarc's http://code.dogmap.org/svscan-1/ , Gerrit Pape's
http://smarden.org/pape/djb/daemontools/noinit.html , and Laurent
Bercot's http://skarnet.org/software/s6/s6-svscan-1.html .
And that's just the process #1 parts.
Reply to: