Hi Laurent ! On 25-03-2013 10:33 Laurent Bercot <[email protected]> wrote:
>> 2) For situations where this it not possible (e.g. Busybox ash) I >> used a simple start wrapper to unblock signals. > > I'm curious: how come your process 1 ash had blocked signals ? Yes curious. I was afraid too. >Process 1 is launched by the kernel, and I haven't heard of a case >where the kernel blocks signals before doing so. Or was it maybe >something in your linuxrc blocking signals and failing to unblock >them ? No it's not the kernel, it is definitely Busybox, as it is the only binary involved in the testing environment. - no linuxrc at all - kernel starts /bin/init - /bin/init is a shell script "#!/bin/busybox sh" - shell script initializes system and mounts things, e.g. /proc - a "cat /proc/1/status" from script shows SIGINT (and others are either blocked or ignored) - script forks and starts a login shell with cttyhack on different console (/dev/tty2) - login shell comes up and looking into /proc it shows SIGINT is either blocked or ignored (depends on Busybox version) - verifying controlling terminal showed /dev/tty is controlling terminal of my login shell and the login shell is running as session leader (setsid after fork). - Ctrl-C doesn't work in this login shell, as SIGINT stays blocked or ignored in contrast: Starting the login shell via a wrapper, unblocking all signals and setting there handler to default enables Ctrl-C in my login shell. As this my /bin/sh is this wrapper. Unblock signals and than exec "/bin/busybox sh" passing through all arguments. ... and everything runs fine. -- Harald _______________________________________________ busybox mailing list [email protected] http://lists.busybox.net/mailman/listinfo/busybox
