On Tue, Aug 26, 2014 at 7:34 AM, Austin S Hemmelgarn <ahferro...@gmail.com> wrote: > On 2014-08-26 01:48, Shea Levy wrote: >> Hi all, >> >> Is there any official documentation of the init process? I'm >> specifically interested in the process state at kernel handoff (argv, >> envp, open fds, etc.) as well as any special properties pid 1 has >> (parent of all orphans, anything else?). >> >> Thanks, >> Shea Levy >> >> P.S. I am not subscribed to LKML, please CC me in responses > This is following is just my understanding based on what I have seen and > read, and I may well be totally wrong on some points (if that is the > case, I would love to know about it, I'm always trying to learn more).
I used to maintain busybox init, and am researching to do a "lunchd" on toybox (mdev is to udev as lunchd is to systemd, think "OSX launchd without the insane xml file formats", only with at least one less letter's worth of functionality), so I have to know far more about this than is strictly recommended. :) > As far as I can tell, the argv that gets passed to the init process is > the concatenation of all arguments on the kernel command-line that the > kernel doesn't recognize or parse. For a definition of "recognize" where each KEYWORD=VALUE gets set as an environment variable, and for the longest time there was this horrible check where any argument with a period in it was jettisoned with "you didn't _really_ mean to say init=/sbin/init.sh" obviously you had some sort of attack, we'll call an ambulance immediately. http://linux-kernel.2935.n7.nabble.com/patch-zap-broken-heuristic-in-init-main-c-td49698.html Presumably fixed long since, but I bring it up to show that the parsing done here is pretty crappy and assumption-filled. (Is there a way to escape spaces in an environment variable you set? Who knows? I couldn't find one when I looked...) > A lot of LiveCD's make use of this > to control hardware detection and module loading. The only open file > descriptors (i believe, I may be wrong) are 0, 1, and 2, all pointing at > /dev/console. Specifically to the /dev/console out of initramfs. If you don't supply an initramfs, it'll fake one for you, but if you _do_ you need a /dev/console in there. (I have a todo item to fix the devtmpfs auto-mount so it actually applies to initramfs/initmpfs instead of only applying to the root= filesystem.) Note that /dev/console is broken, and does not provide a controlling tty. I have no idea why this is the case, but it's been that way forever. The dance you have to do to get a shell prompt that actually responds to ctrl-c and ctrl-z is: http://landley.net/hg/toybox/file/tip/toys/other/oneit.c > As for special properties: > * Parent of all orphans Because I complained about this in early 2.4 and Andrew Morton added reparent_to_init. :) Now that we have containers, the container init process > * Doesn't have a session ID until it calls setsid() (not certain about > this one) News to me. > * Calling exit() will cause either a reboot or possibly a panic (I > think that this is dependent on the argument passed to exit()) No, it's a panic. You can set "panic=1" on the kernel command line to convert all panics into a reboot after a 1 second delay. There's a mostly complete list of kernel command line options at: https://www.kernel.org/doc/Documentation/kernel-parameters.txt (And there's some syntax for passing arguments to statically linked modules that I never remember. Might be involved with that dot nonsense mentioned above.) > * Not catching a fatal signal will cause a panic (this means that > sending SIGKILL and SIGABRT to PID 1 will always cause a panic). No, the kernel starts with SIG_IGNORE on all signals. If you supply a handler, your handler gets called. If you don't supply a handler, the signal is ignored. > * Has a PPID of 0, only other process like this is kthreadd Or the init task within any container (I.E. the first process in any new PID context. "man 2 clone" and then look for CLONE_NEWNS.) > * Becomes the parent of most X programs (almost all of them dissociate > very quickly from whatever started them. That's another variant of "reparent to init", above. Note that if the SIGCHLD handler is set to SIG_IGNORE then the zombie trying to deliver a signal is allowed to finish exiting with its status discarded. So reparenting to init is just one way to prevent zombies from accumulating. Rob -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
