OK, so I have analyzed how a Debian Linux system boots. (Debian 6.0 with a 2.6.32 kernel, but I don't think it has changed much with newer kernels.
The process is incredibly bloated - and I strongly suspect other mainstream distributions are just as bad, if not worse. Those guys do a lot of work in a pre-init initramfs; work that could easily be done in the real system, without an initramfs, if only people would realize that "init" is nothing sacred and can actually be a script that does early stuff before launching the long-running binary - which is actually exactly what they do, except they're hiding it in an initramfs as if it was shameful. I'm mentioning it because I had to dive deep into it to track the information I was looking for, and unneeded complexity in the boot process is one of my pet peeves. The binaries that run as process 1 before /sbin/init (which in my case is a SysVinit, but it would be the exact same thing with a systemd or anything else) are: * the initramfs shell, which is actually a Busybox shell. (I do not know whether it's hush or ash.) It is the first actual userspace binary launched by the kernel. * initramfs-tools' "run-init" binary, which acts as a transition between the /init shell script and the long-running /sbin/init binary. (Yeah, looks like they didn't manage to perform everything they wanted in the /init shell script, so they *still* had to insert some C code there. So much for flexibility and maintainability. Oops, I ranted again.) The run-init binary performs no signal handling at all. So if a some code performs signal blocking/unblocking between the kernel and the init process, it has to be the Busybox shell. Right before /sbin/init is launched, /proc/1/status shows *no* blocked signal. I haven't delved into ash and hush's source, because other people here will know their internals better than I will, but my conclusion for now is that it is *very unlikely* that the "initial process 1 sigmask" idea has anything to do with the problem. - Either the Linux kernel passes an empty sigmask to its first userspace binary (which I strongly believe is the case), and there is no problem here; as I already said, go investigate tty and job control, where unholy magicks are at work. - Or the Linux kernel passes a nonempty sigmask to process 1; but then the Busybox shell actually performs active sigmask management, since when it execs into something else, it has an empty sigmask. So in this case: * either it manages its sigmask correctly from the start, and there is no problem here - look somewhere else; * or it only cleans up the sigmask when executing, and incorrectly keeps some inherited blocked signals in its main loop. I'll leave the refutation (or bugfix !) here to the busybox shell experts. I'm still interested in hearing Rob on the inherited process 1 sigmask thing, or even in just pointers to relevant kernel-dev discussions. -- Laurent _______________________________________________ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
