On 03/30/2013 05:34 AM, Laurent Bercot wrote:
So perhaps the confusion is that Linux is simply not delivering
the signal (regardless of sigprocmask) unless you install a signal
handler.
No, this is not the problem. Every shell in the world traps SIGINT.
Hm, true... but then the problem you actually have is that there
might be signals that the shell is allowing to be delivered that you
didn't expect.
I question whether anyone would actually want to write a
shell script with signal handling to act as "init"... that seems
messy and error prone.
Lots of people do that, and for good reasons: see
http://skarnet.org/software/s6/s6-svscan-1.html
You make great arguments for stage 1 and 3, but it still seems a
shell is ill-suited for stage 2. You would have to handle any
signal where you didn't want the shell's default behavior, and
if I remember right, there was also a trick needed to get the
shell to reap zombies.
It just seems too easy to write a tiny C program that
1 - launches a supervisor
2 - reaps zombies
3 - runs a script when it receives signals
4 - execs stage 3 when the supervisor exits
Not to mention the large number of supervisor programs that
already do this.
I use shells as init sometimes, but mostly just for diagnostics.
I'm not even sure if there is a command-line access to this call.
echo 0 > /proc/sys/kernel/ctrl-alt-del
Ah, nice.
-Mike
_______________________________________________
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox
