> Back to the keyboard, I just discovered, that every (GUI) program I > run, is spawned from PID 1. Honestly, I would have expected those to be > child processes of e.g. the display manager or the session manager...
That isn't how it starts off, chances are that when you run a program it is spawned (well, forked, err, cloned) by a process that you own (so *not* pid 1). Important is to know that unix requires *almost every* process to have a parent process. You can get this information with getppid (man getppid), and ps will show it to you. One of the reasons for this is to report the exit code to somebody (man wait ; less /usr/include/sysexits.h) to somebody. A process which hasn't had its exit code collected will hang around in a zombie state (Z in the ps listing) - zombie because it is dead, but still occupies a process table entry, which is a finite resource. So: What happens if a parent process goes away ? Well, the kernel reparents the children so that they are now direct children of pid 1, aka init. And that is what thing that makes pid 1 special[1]. It can't crash/exit/hang because then you'd run out of process table entries which means the whole system hangs. Actually linux will move that forward, and have the kernel panic on init exiting - where would it's status code go, anyway ? So pid 1 - init's main job is to wait for all processes which have lost their parent. Init adopts orphan processes. And if you know that you are almost ready to write your own init. It also happens to be why this mailing list exists: init processes can't crash and so should be simple. regards marc [1] There is some fine print - modern linux allows you to delegate this function to other processes, but just because you can does not mean you should. _______________________________________________ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
