> You make great arguments for stage 1 and 3, but it still seems a > shell is ill-suited for stage 2. You would have to handle any > signal where you didn't want the shell's default behavior, and > if I remember right, there was also a trick needed to get the > shell to reap zombies.
Oh, I wasn't arguing about stage 2 at all. Having a shell as process 1 is either stage 1 or stage 3, or debug/recovery mode with an interactive shell, which causes the infamous "job control turned off" problem cttyhack is supposed to work around. I agree it is totally nonsensical to use a shell as a normal stage 2 process 1. > It just seems too easy to write a tiny C program that > 1 - launches a supervisor > 2 - reaps zombies > 3 - runs a script when it receives signals > 4 - execs stage 3 when the supervisor exits > > Not to mention the large number of supervisor programs that > already do this. runit does exactly that. s6-svscan also does that - except it is, strictly speaking, the supervisor. Process 1 management is a solved problem, has been for a while now, and that's why I can rant on and on about it when presented with less-than-optimal (to remain civil) solutions. ;) SysVinit being one of them. systemd being another. We've strayed far away from the OP's question, and I'm afraid I'm the main culprit. My apologies. Denys' answer looks promising to me, however - much more promising that the "kernel starts init with a nonempty sigmask" hypothesis, which I've only been able to find evidence against. -- Laurent _______________________________________________ busybox mailing list [email protected] http://lists.busybox.net/mailman/listinfo/busybox
