When PID=0 in early kernel_init, PID=1 has a skeleton running, this
detection is not
the Busybox /sbin/init, but a place holder for when the real Busybox
/sbin/init is do_execve'd
Are you saying the kernel could spawn a /sbin/reboot process *before*
kernel_init execs into the userspace init?
If it's the case (and Denys' test will verify it), it's violently out
of spec. There should be no other userspace processes present before
init, and if there are, the behaviour is totally undefined, and things
should very much be expected to fail. It is basically impossible to
program under Unix if you cannot assume there is a pid 1 present that
will reap zombies.
It would be worth it to report the situation to the kernel maintainers
so they make sure the spawning of userspace processes (triggered by
soft-poweroff or anything else) is deferred until after /sbin/init has
been do_execve()'d.
--
Laurent
_______________________________________________
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox
