Hi Laurent, just a quick response as I'm late and busy today ...
> I haven't delved into ash and hush's source, because other people here >will know their internals better than I will, but my conclusion for now >is that it is *very unlikely* that the "initial process 1 sigmask" idea >has anything to do with the problem. You tell me truth about those distro startups. Therefore I striped that down to nothing! On my systems the kernel start a shell script from mine which does necessary initializations and then the scripts exec's my applications main, a very minimalist program, which does nearly nothing until it receives a signal. Based on the received signal it does exec another script of mine to shutdown the system. > - Either the Linux kernel passes an empty sigmask to its first > userspace >binary (which I strongly believe is the case), and there is no problem >here; as I already said, go investigate tty and job control, where >unholy magicks are at work. > - Or the Linux kernel passes a nonempty sigmask to process 1; but >then the Busybox shell actually performs active sigmask management, >since when it execs into something else, it has an empty sigmask. So >in this case: > * either it manages its sigmask correctly from the start, and there > is >no problem here - look somewhere else; > * or it only cleans up the sigmask when executing, and incorrectly >keeps some inherited blocked signals in its main loop. I'll leave the >refutation (or bugfix !) here to the busybox shell experts. > > I'm still interested in hearing Rob on the inherited process 1 sigmask >thing, or even in just pointers to relevant kernel-dev discussions. It is not only the sigmask issue. I noticed two things which may leed to a blocked signal situation. First is a sigmask blocking SIGINT and the second is SIGINT being ignored. And especially leads to trouble with Ctrl-C in the shell, as the shell does not enable SIGINT, if it is ignored on entry (feature not bug). So you need to check which issue is blocking your interrupt ... or you just unblock and restore all SIGs to there default action. ... it's a really simple wrapper to have as either /bin/sh or /bin/init to just do that signal unblocking than execve with the original arguments to /bin/busybox. This enables usage of a shell script as a long lived process 1 ... works since Linux kernel 2.2.1 on several of my Boxes without any failures. This shows the problem is not, Busybox doing something wrong. It is just Busybox is missing to do something, required to enable normal signal response (in some usage cases, because getty seems to correct that problem - in getty started sessions everything looks fine). A suggestion: Add that signal unblocking stuff to cttyhack. If one needs to run shell scripts directly or has some corresponding trouble, he can run those applications trough an "exec cttyhack". -- Harald _______________________________________________ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
