Re: Documentation for init

[Austin S Hemmelgarn]

On 2014-08-26 18:00, Rob Landley wrote:
> On Tue, Aug 26, 2014 at 7:34 AM, Austin S Hemmelgarn
> <ahferroin7@xxxxxxxxx> wrote:
>>  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.
> 
I think now (after reading the rest of your e-mail) that I am wrong
about this.  I assumed that this was the case because I had heard
something about needing to call setsid() to get a shell to behave
properly when started as init.
>>  * 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.
> 
Yeah, I usually use panic=-1 when I'm not doing debugging, so I can't
always tell the difference.
> 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.)
> 
Yeah, the dot thing is a result of using that for statically linked
modules (ie, to pass the argument bar to statically linked module foo,
you specify foo.bar on the kernel commandline).  There are still some
edge-cases here where things that should work don't, I keep meaning to
look into this code further, but never have had the time.
>>  * 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.
I actually hadn't realized this, are you sure that it does that for all
signals?  If that is the case, then there must be some special handling
in the kernel for if init does something to get a SIGSEGV or SIGFPE that
it doesn't set a handler for.

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature