[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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: