On 03/29/2013 11:56 AM, Harald Becker wrote:
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?
Linux 3.0.0 and 3.6.11 do not mask any signals.
And it's easy to find out!
/root # gcc init-debug.c
(see attached init-debug.c)
followed by editing grub's boot line during a reboot:
kernel (hd0,0)/vmlinuz-... root=/dev/sda2 init=/root/a.out
revealing
SigPnd: 0000000000000000
ShdPnd: 0000000000000000
SigBlk: 0000000000000000
SigIgn: 0000000000000000
SigCgt: 0000000000000000
CapInh: 0000000000000000
CapPrm: ffffffffffffffff
CapEff: ffffffffffffffff
CapBnd: ffffffffffffffff
Meanwhile, the man page for kill (2) says:
The only signals that can be sent to process ID 1, the
init process, are those for which init has explicitly
installed signal handlers. This is done to assure the
system is not brought down accidentally.
So perhaps the confusion is that Linux is simply not delivering
the signal (regardless of sigprocmask) unless you install a signal
handler. 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.
Anyway, this little test also reveals that (as I thought I remembered)
you have to make a special syscall to get the ctrl-alt-del behavior.
Namely,
reboot(RB_DISABLE_CAD);
causes the system to stop instantly rebooting when ctrl-alt-del is
pressed, and instead send SIGINT to pid 1. I'm not even sure if
there is a command-line access to this call. I've only ever done
it from C.
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.
Can you name any actual cases where busybox caused signals to be
blocked?
Again, I'm suspecting that the real problem all along was either a
missing call to reboot (2) or not installing a handler and causing
the kernel to not deliver the signal.
-Mike
#include <stdio.h>
#include <sys/fcntl.h>
#include <sys/mount.h>
#include <string.h>
#include <signal.h>
void sig_handler(int sig_num) {
fprintf(stderr, "Caught signal %d\n", sig_num);
}
int main() {
char buf[4096];
int fd, got, i;
struct sigaction sa;
if (mount("proc", "/proc", "proc", 0, "") != 0)
perror("mount(proc)");
if ((fd= open("/proc/1/status", O_RDONLY)) < 0)
perror("read(/proc/1/status)");
got= read(fd, buf, sizeof(buf));
sleep(5);
write(1, buf, got);
memset(&sa, 0, sizeof(sa));
sa.sa_handler= &sig_handler;
for (i=0; i<64; i++)
if (sigaction(i, &sa, NULL) < 0)
fprintf(stderr, "Can't listen to signal %d\n", i);
fprintf(stderr, "Entering infinite loop\n");
while (1)
sleep(999);
}
_______________________________________________
busybox mailing list
[email protected]
http://lists.busybox.net/mailman/listinfo/busybox
