Zombie processes and cant reboot/shutdown when --enable-emergency-shell

[xhebox]

Me again :).

In short, processes that invoked fork() are likely to be Z. Processes closed manually was the same. And by reboot, i mean i can execute the reboot command, but no shutdown progress was shown, no reaction.

I have checked the corresponding the code, and i guess, finit.c:212 if (pid != 0) and finit.c:213 waitpid(0... should be the solution. Because emergency shell should start right after the crash in my view. So some undefined behavior was executed unexpectedly, that's what i though.

That's all.

[troglobit]

Hi! :-)

Yeah, it's sort of a limitation with that implementation. Finit doesn't run as PID 1 with --emergency-shell so you have to do a reboot -f to sidestep Finit.

I will look into your suggestion, but in all honesty I think the best approach would be to improve the documentation around --emergency-shell .. if shipped on a production system it would be a potential security risk (root shell w/o entering credentials).

The second part of this report (startx++) I'd prefer if you report separately. Much easier to follow up on.

[troglobit]

I've created a branch for improving emergency shell mode a bit, the first patch is in 054baed. The next step will be to update the documentation, to clarify this mode's intended use.

Any feedback is welcome. If you want I can also explain a bit more about how it works and its inherent limitations.

[xhebox]

Sorry for my late reply, i'm getting a little busy as the last year in high school has come.

Patch is OK(though i still need to reboot manually). And, of course, i'd like to learn more about what happened, never get bored about the fresh. :)

[troglobit]

The forced reboot is still necessary, yes, and services that die are not respawned automatically.

At the center of it all is the fact that PID 1 has some "magical" powers since it's the first process started by the kernel and if it crashes the kernel deems the system unsound and usually reboots. This is what the rescue mode rather clumsily tries to avoid. With it enabled the actual Finit process runs as PID 2 and if Finit dies the rescue shell (which is the actual PID 1) is activated.

Now, many daemons have a "reparent to init" sort of code, some call daemon(3) to achieve this. Meaning, hat the PPID of the daemon process is set to 1. So PID 1 will get a SIGCHLD signal telling it a child has died. PID 1 then has to collect (the term 'reap' is sometimes used, jokingly referring to the grim reaper ...) the child using wait(2) or similar. If wait() is not called the process is not collected and remains a zombie process.

This latter collect of children is used by Finit to see if the PID was a service to be respawd, TTY or inetd. If the PID matches any of them (and its conditions is fulfilled) Finit will restart it. When Finit runs as PID 2 this will not be possible unless some extra overhead like IPC between the actual PID 1 and PID 2 is added.

Therefore, --enable-emergency-shell is to me only a last resort debug mechanism for developers and system engineers/integrators when first starting out with Finit.

Hope that explains it a bit more.

[xhebox]

enough, i think, close