#software hairsplitting

[mentalisttraceur-software]

Actually, in principle, PID 1 in a UNIX-like system only needs to

fork and execute one child, then

reap any process exits that it receives.

Notably, init does not have to pass the PID and exit information of reaped orphans anywhere, like I said in a prior post. Not in the strictest sense. Not if you have some other satisfactory means of reacting to the deaths of processes that only init can reap.

These are the only things that absolutely cannot move out of init because:

Traditional user-space initialization in UNIX only starts the init process - nothing else runs in user-space unless init starts it, so you want more than one process, init has to fork once.

PID 1 has final responsibility for preventing a resource leak by reaping zombie process entries from each process that got orphaned by its parent - and subreapers if it had any.

The only way to have other functionality be implemented outside of the init binary - or outside of dynamic libraries that init loads - is to have init exec a different binary.

Put those three together and you get the minimal necessary feature set. Fork, parent moves on to the reaping loop where it mostly idles in the wait system call, child moves on to exec.

You could also split the fork-and-exec part and the reaping-loop part into separate binaries. Of course then you have to exec in the parent as well, and either hard-code one more path, or complicate the CLI interface, or both.

[mentalisttraceur-software]

If we want PID 1 to support upgrades without rebooting, it also must have some way of being told to execve another program.

So to add that feature, the executable that contains the PID 1 reaper loop must also have a code path for executing a command, and a code path for some kind of signaling mechanism.

The signaling mechanism could in principle be anything - native signals, reading from a pipe, polling the file system, abuse of the wait system call by creating an orphan process and having it exit with a very specific status or kill itself with a very specific signal, and so on.

That last one is probably a terrible idea, but I wanted to mention it because it's the only mechanism that doesn't require adding a different code path for interfacing with the outside world differently to an as-minimal-as-possible init.

But signal handler is probably the most appropriate thing to do here, even though a most minimal init doesn't strictly speaking need to have a signal handler - if you're doing something more complicated you might need to handle SIGCHLD, but if the init is doing nothing except waiting on process exits, SIGCHLD is redundant.