Hi Denys ! >> Hence my suggestion to add this sigprocmask to unblock all signals >> *AND* restore all signal actions to there default as part of the >> cttyhack applet. > >I would like to hear people confirming that kernel indeed blocks >ant signals to pid 1. Which kernel version does that?
May be you narrowed your focus a bit to much to the kernel. Sorry for my bad English and the misunderstandings it may produce. I'm no native English speaker. To clarify it a bit: - On Linux system startup from bare kernel to nothing else than a Busybox binary (startup script), I noticed at several times / system constellations issues due to signal actions not being processed. - Digging a bit into this, I found signals being either blocked (sigprocmask) *OR* ignored (action = SIG_IGN). - As at least some 2.4er Kernels mangled with the signals on startup, I did not look for the real reason of such signal blocking. I just added a simple wrapper to release the blocking that may have occurred ... and everything was fine for me. - As someone was asking for a problem which may be the result of such blocked signals I wanted to give a hint, why the signal may not be processed, even if you do a kill -SIGINT 1. - Restoring all signals action to there default and unblocking, before doing an exec to another program is good programming practice. To avoid searching for all the cases where this need to be done, I focused on the question, when is it required. Except the case of init it matters only when an interactive shell is started, as daemons usually setup there own signal handling without respect of signal setting on entrance. So the central place to trow that signal unblocking/default action restoring is the place used to startup the shell, usually the cttyhack applet. - Restoring signal actions to there default and unblocking doesn't harm if it's done without being required. It just waste some time/code space, but avoids lengthy debug sessions due to blocked signal handling. -- Harald _______________________________________________ busybox mailing list [email protected] http://lists.busybox.net/mailman/listinfo/busybox
