On Friday 24 February 2012 21:35, Laurent Bercot wrote: > >> [ Side note : panicking when process 1 exits is a *very* silly thing > >> for the kernel to do. Process 1 exiting, instead of being forbidden, > >> should mean the end of the machine's life cycle, and the kernel should > >> either halt, reboot, or even kexec something else, depending on process > >> 1's exit code. But that is totally off-topic. ] > > > > I suspect there might be ugly race conditions in this case (in the > > window between process 1 ceasing to exist and the system shutting > > down or doing whatever) > > Race conditions ? The semantics I'm suggesting are perfectly clear and > atomic. Process 1 exits -> the kernel reads its exit code and performs > a reboot(), poweroff() or kexec() system call, *at once*. > > > > and there's also the issue of special-casing > > who gets the SIGCHLD, and whether process 1 would be zombie, etc. when > > init terminates. > > If process 1 terminates, UNIX semantics are done for. From the moment > process 1 dies and the system enters kernel space to handle this death, > the system never goes into user space again.
Think about SMP systems... -- vda _______________________________________________ busybox mailing list [email protected] http://lists.busybox.net/mailman/listinfo/busybox
