Subject: ash leaving SIGINT ignored - msg#00063

[System: mipsel, Linux 2.4.19 kernel, busybox @ April 17th - more at end]

I am seeing some very odd behaviour which appears to involve ash and SIGINT,
and I'm wondering if anybody else has seen this and knows of the cause (and
solution :-)

It appears that ash ignores SIGINT (and SIGQUIT) at various points during its
execution and fails to unignore them in certain circumstances. This was
noticed because people were running "tail -f /var/log/messages" and found
that they couldn't stop the program with ^C. Opening a telnet session to the
box and finding the PID of tail and issuing "kill -INT pid" also did not stop
the program.

Looking at /proc/pid/status shows that as far as the kernel knows, the signal
is ignored (its bit in SigIgn is set), along with SIGTTOU, SIGTSTP, SIGTERM
and SIGQUIT.

^C is bound correctly in the terminal. It makes no difference whether the
tail is run on the serial console or a telnet session. It doesn't have to be
tail - other utilities suffer the same problem (perhaps it could be related
to things which are doing blocking system calls?).

To eliminate the possible interference of external applications, I switched
to testing this using "trap". So with 'trap "echo sigint received" 2' set, I
press CTRL-C. I just get the shell prompt printed again and no message.

Other things tried: taking /bin/bash and running that. The trap does work in
that, but if I start ash and try in ash, it doesn't work in ash BUT it then
appears to stop working in bash too - either in the parent shell or in a
sub-shell of ash.

The behaviour seems to be extremely inconsistent and not reliably
reproducible. The trap test seems to reliably not work most of the time, but
does work occasionally. We have devised several test scenarios but find that
executing the tests under (at least what appear to be) identical conditions
give us different results.

This is driving a lot of us barmy here - does anybody have any idea what
could be causing this? A bug in ash? A bug in the kernel? A bug in
something else?

Another test we tried was to alter the /etc/init.d/rcS script (which will be
being executed by ash) to cat the /proc/$$/status file, set the trap and then
"kill -INT $$". *No* signals were ignored in SigIgn and the signal was
caught and the message was printed. This is reproducible (5 times). The
inittab file contains just:

::restart:/sbin/init
::respawn:-/bin/login
::sysinit:/etc/init.d/rcS

This is using busybox's init. /bin/login contains:

#!/bin/sh
exec /bin/sh

(i.e. it gives you a shell straight away with no authentication).

More details on setup:

Little-endian MIPS R4Kc processor, busybox 0.61 development version as of
April 17th 2003, Linux kernel 2.4.19 from linux-mips.org with board-specific
additions and drivers. ash is the default shell. Job control is enabled.



--
Stewart Brodie, Senior Software Engineer, available from the end of June