from the last replies we have the following possibilities regarding process #1's supervision capabilities:
- no supervision/respawning (maybe also not handling system shutdown at all, too): simplifies the process #1 implementation (especially in the latter case), supervision can be delegated to a subprocess which also simplifies that supervisor's implenation since there is no need for it to handle process #1 specific duties (given there are more than just reaping zombies as the default subreaper and successfully starting at least one necessary child process (to which the remaining duties are delegated)). disadvantage: "incorrect" behaviour when all other processes die, leads to a bricked system, deep shit ahead. - respawning (at least one) given services/daemons, possibly even with log output redirection to logger processes (s6-svscan et al) - a compromise between the above 2 solutions: process #1 supervises (i. e. respawns, possibly only under certain conditions) at most 2 subprocesses (a real "supervisor") and maybe redirects its output via pipe(2) to a separate supervised dedicated logger subprocess. in that case those child processes should only be respawned under certain conditions (respawn throttling maybe, i. e. stop respawning if one of the 2 repeatedly fails in a certain amount of time). if those conditions are not met it should start a single user rescue shell (possible via sulogin) and/or reboot. only in case the logger child process repeatedly fails: do not redirect the supervisor's output, use our own (possibly opened by the kernel) output fds for the supervisor child process (probably the console device) instead of the pipe fds. it could also be a good idea to close all of process #1 stdio fds and only open the console device for output when the need arises. this has the advantage that we do not have this device open all the time (in case /dev needs to get re/unmounted). again (as we are at it ;-): in the last case: when said "supervisor" is s6-svscan (or perpd for that) it would be helpful for the process #1 implementor (me) if it could manage its own output logger via a command line option (akin to dt encore's "svscan") since it saves him from opening the pipe, comparing terminated child PIDs with an additional (the logger's) PID, and managing additional emergency situations caused by the logger's failure himself (especially since s6-svscan does a lot of additional stuff like catching signals and running the corresponding scripts anyway). :PP