> If your oneit command is started with blocked signals or there action > has been set to SIG_IGN this setting is inherited by the command you > start. So it is better to set all signals to there default action and > unblock before you do your exec. This way the started program has a > clean signal handling on it's own session/process group.
Hi Harald, I believe Bastian was just quoting the oneit page to mention that "PID 1 is special". It seems that the kernel sometimes launches process 1 with a nonempty set of blocked signals - apparently, Rob says so. I have never personally witnessed it, but getting a clean sigprocmask is one of the first duties of a long-running process 1, so it's not commonly observable. It makes sense that a shell running as process 1 (which it's not designed for) would have some trouble in this case because it has no reason to sigprocmask the world; but it's very weird that it wouldn't receive SIGINT, because a shell does want to catch, and actually handle, SIGINT, so it has to sig_unblock it sooner or later. I will experiment tomorrow, but my money isn't on the nonempty pid 1 sigprocmask thing. It's still on a tty/job control issue, which is far more voodoo (including the bloody, gory entrails) than signal stuff. -- Laurent _______________________________________________ busybox mailing list [email protected] http://lists.busybox.net/mailman/listinfo/busybox
