Martin Read:
1. The init daemon should fork exactly once; in the child it should
> exec another program, while the parent (PID 1) does nothing except
> reap zombies.
> 2. As (1), except that if the initially-forked child process exits,
> PID 1 should repeat the fork and exec-in-child procedure.
Whilst you were primarily making a point about the idea of requring
interchangeability of tools that involve different design decisions, you
did make a common error in two of your examples that should be
addressed. Whilst these are commonly-held positions, they are only
commonly held by people who have never actually written a process #1
program that functions in production systems; because experience (as I
can attest) teaches otherwise. There are, in fact, several things that
various operating system kernels and other programs demand of process #1
that one simply cannot escape. People think, as above, that acting as
the parent of orphaned processes is the prime function. Ironically, it
is (with recent Linux kernels) a part the system that one can largely
factor out of process #1 into other processes, whilst the things that
people usually forget in their off-the-top-of-the-head designs (such as
handling SIGINT, SIGPWR, SIGWINCH, and so forth sent from the kernel and
enacting the various system state change requests) are the parts that
one cannot. To see what one actually has no choice but to do in process
#1 programs, look at the overlaps in the operation of Gerrit Pape's
runit, Felix von Leitner's minit, and the system-manager program from
the nosh package.
--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/546f44d3.9010...@ntlworld.com
