Re: Documentation for init

From: Rob Landley
Date: Tue Aug 26 2014 - 18:00:41 EST

On Tue, Aug 26, 2014 at 7:34 AM, Austin S Hemmelgarn
<ahferroin7@xxxxxxxxx> 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/" obviously
you had some sort of attack, we'll call an ambulance immediately.

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:

> 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:

(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.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at