|
|
|
|
|
|
by bitwize
894 days ago
|
|
|
What Lennart found is that pid 1 is the only process in the whole userland that can ensure a process is terminated without risk of race conditions. Hence, all the process management stuff HAS to be in pid 1 in order to provide consistency guarantees. Hence, systemd. |
|
|
In other words, it has historically been the program/process used to manage other programs/processes.
Consider the simplest possible Unix/Linux system with only two user-space processes. For a Kiosk, let's say.
The first user-space process/program is 'init'.
The second (and last!) user-space process/program is the kiosk software itself. Call it KIOSK.EXE (or /usr/bin/kiosk -- since this is Unix/Linux, or what-have-you)
OK, so now here's the problem!
What should happen if KIOSK.EXE or /usr/bin/kiosk -- should fail for some unexpected reason?
Some stack-heap collision, some segmentation fault, some core dump, some "blue screen of death", some abort, some failure...
OK, so now how do we:
a) Monitor that kiosk software to know if its up and running;
b) Bring it back up and running if it has crashed?
Well, if there's only 'init', aka the PID 1 program/process in the system (other than the kiosk software, and the kiosk software is crashed, no longer functional) -- then it must be 'init' (or PID 1's) responsibility to bring 'kiosk' back up!
To get 'kiosk' back up and running!
That's WHY the "process management stuff" functionality -- historically has been placed into 'init' (PID 1) -- simply because there was no other easy/simple/straightforward/obvious/user-friendly place to put it!
But 'init' ultimately is just a user-space program.
It could be programmed to do nothing, it could be programmed to do everything (its code could in theory be fused with the kiosk program, although then it becomes the OS's responsibility to restart that program if it crashes!)
But ultimately 'init' -- is just a program!
It could, if programmed to, do whatever any other user-space program could do.
It could also be programmed not to do anything -- or offer the barest minimal functionality.
What 'init' does or does not do, or is supposed to do or not supposed to do -- is truly at the behest of any programmer who wish to work with the source code of 'init', in whatever form that may take...
Nothing "HAS to" be any particular way for any OS or user program if you have the source code, if you know what it does, and if you know what you are doing...
There are no "HAS to's" -- for those that have source code and understand it.