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.
