how a proper init process should work

Should not be using valuable time to post this today.

This post

https://lists.debian.org/debian-user/2017/04/msg00441.html

to the debian users mail list, and my response to it:

https://lists.debian.org/debian-user/2017/04/msg00443.html

reminded me of this blog post

http://reiisi.blogspot.jp/2014/10/thinking-about-ideal-operating-system.html

that I wrote back in 2014.

I think I want to post the meat of that here, without the complaints about systemd, and with a little explanation.

(If someone were to implement these ideas, it would require a fork of the OS distribution to keep things sane, of course. It would likely also require a fork of the kernel.)

Now, if I were designing an ideal process structure for an operating system, here's what I would do:

Process id 1, the parent to the whole thing outside the kernel, would

• Call the watchdog process startup routine.
  
  • It (process id 1) would not itself be the watchdog process, because pid 1 has to be simple.
  • The process watchdog routine would probably need some special mutant process capabilities.
  • The changes may ripple back to the kernel.
  • But such changes would be better than adding complexity to pid 1 to directly handle being the watchdog of everything.
• Call the interrupt manager process startup routine.
  This may be obvious, but you do not want pid 1 managing interrupts directly. That would provide too many opportunities for pid 1 to go into some panic state.
• Call the process resource recycling process startup routine.
  Recycling process resources must be kept separate from catching dying processes.
  
  • You don't want an orphaned process to have to wait for some other process to have it's resources recycled, just to be seen.
  • And you don't want that complexity in pid 1.
• Call the general process manager process startup routine.
  
  • This is the process which interacts with ordinary system and user processes. 
  • Most orphan processes would be passed to the process recycling process by this process.
• Enter a loop in which it 
• monitors these four processes and keeps them running, restarting them when necessary --
  (Ergo, who watches the watchdogs, erm, watchers? -- Uses status and maintenance routines for each.);
• collects ultimately orphaned processes and passes their process records to the resource recycler process;
• and checks whether the system is being taken down, exiting the loop if it is.
• Call the general process manager process shutdown routine.
• Call the process resource recycling process shutdown routine.
• Call the interrupt manager process shutdown routine.
• Call the watchdog process shutdown routine.
• Call the last power supply shutdown driver if not a restart.
  (Note that this defines an implicit loop if it is not a full shutdown.

All other processes, including daemons, would be managed by the process manager process.

This would break a lot of things, especially a lot of things that interact directly with the pid 1 process (e. g., hard-coded to talk to pid 1).

Traditional init systems manage ordinary processes directly. I'm pretty sure it's more robust to have them managed separately from pid 1. Thus the separate process manager process.

There are a few more possible candidates for being managed directly by pid 1, but you really don't want anything managed directly by pid 1 that doesn't absolutely have to be. Possible candidates, that I need to look at more closely:

• A process/daemon that I call the rollcall daemon, that tracks daemon states and dependencies at startup and during runtime. 
• A process/daemon to manage scalar interprocess communication -- signals, semaphors, and counting monitors.
  (But non-scalar interprocess communication managers definitely should not be handled directly by pid 1.)
• A special support process for certain kinds of device managers that have to work closely with hardware.
• A special support process for maintaining system resource checksums.

Processes I consider ordinary processes to be managed by the general process manager, instead of pid 1, are basically everything else, including

• Socket, pipe, and other non-scalar interprocess communication managers,
• Error Logging system managers,
• Authentication and login managers,
• Most device manager processes (including the worker processes supported by the special support process I might have the pid 1 process manage),
• The actual processes checking and maintaining system resource checksums,
• Etc.

Definitely, code to deal with SELinux, Access Control Lists, cgroups, and that kind of fluff, should be managed by ordinary processes managed by the general process manager.

For me, this is daydreaming. I don't have the job, the cred, or the network that could put me in a position where would I have the time or resources to code it up.

I would love to, if I can find someone to front me about JPY 400,000 (USD 4,000.00) a month for about a year's work, plus the hardware to code and debug on (between about JPY 500,000 or USD 5,000.00 and double that).

[JMR201704211138: I had some thoughts on the low-level boot process, which might be interesting: http://defining-computers.blogspot.com/2017/04/model-boot-up-process-description-with.html.]