Stable kernel 2.6.25 released [LWN.net]

Stable kernel 2.6.25 released

Posted Apr 19, 2008 7:41 UTC (Sat) by michaelk (subscriber, #1978)
In reply to: Stable kernel 2.6.25 released by willy
Parent article: Stable kernel 2.6.25 released

> Now, just press ^C, ls will die and you get
> your prompt back.

Willy, you say ^C (i.e., SIGINT), but looking at fatal_signal_pending() the only signal that
seems to be matched is SIGKILL, so I'd have thought ^C wouldn't be sufficient.  What am I
missing?

(Log in to post comments)

^C vs SIGKILL

Posted Apr 19, 2008 13:27 UTC (Sat) by willy (subscriber, #9762) [Link]

You are entirely correct in that ^C by convention sends a SIGINT to the current foreground
process.  The kernel translates unhandled terminating signals into SIGKILL, so all I have to
do in my patchset is check whether SIGKILL is pending.  If the process has installed a handler
for SIGINT, pressing ^C will have no effect and you will have to resort to kill -9.  So I was
being sloppy when I said ^C, but most processes do not install a handler for SIGINT, and so
will receive a SIGKILL when the user presses ^C.

One notable task which does install a handler for SIGINT is bash, so trying to do filename
completion on a down NFS server will cause bash to only be killable by -9.  That's a user
experience I'd like to improve, but I haven't come up with a good solution yet.  I have some
bad solutions:
 - fork() in bash to do filename completion.  Who wouldn't love a fork() to happen every time
they press tab?  ;-)
 - Introduce new readdir() variants which indicate they're interruptible (not just killable),
then percolate that knowledge all the way down the stack.  IIRC, Linus already NACKed that
idea.

Thanks for asking the question.  Signal handling is a complex beast, and I initially thought
that I was going to have to do a more complex check for fatal_signal_pending(), but I just
implemented the check for SIGKILL first, and to my surprise ^C worked, so I dug a little
deeper and found the translation.  Rewarded for being lazy ... who doesn't love that ;-)

^C vs SIGKILL

Posted Apr 19, 2008 14:21 UTC (Sat) by michaelk (subscriber, #1978) [Link]

> The kernel translates unhandled terminating signals into SIGKILL

Where does that translation occur?  I couldn't see it.

^C vs SIGKILL

Posted Apr 19, 2008 14:31 UTC (Sat) by willy (subscriber, #9762) [Link]

I see two places where we send SIGKILL in kernel/signal.c.  The first is in
__group_complete_signal():

        if (sig_fatal(p, sig) && !(p->signal->flags & SIGNAL_GROUP_EXIT) &&
            !sigismember(&t->real_blocked, sig) &&
            (sig == SIGKILL || !(t->ptrace & PT_PTRACED))) {
[...]
                        do {
                                sigaddset(&t->pending.signal, SIGKILL);
                                signal_wake_up(t, 1);
                        } while_each_thread(p, t);

The second is in zap_other_threads():
                sigaddset(&t->pending.signal, SIGKILL);
                signal_wake_up(t, 1);

I'm pretty sure the first case is where it happens.

^C vs SIGKILL

Posted Apr 19, 2008 17:14 UTC (Sat) by michaelk (subscriber, #1978) [Link]

> I'm pretty sure the first case is where it happens.

Yes, looks right to me.  Thanks for the pointer.

^C vs SIGKILL

Posted Apr 21, 2008 7:18 UTC (Mon) by tialaramex (subscriber, #21167) [Link]

I think leaving bash hung-up until a system administrator sends KILL to it is acceptable in
this circumstance. I'd say the same about server applications I've written which have a signal
handler only to write a log message explaining why they died (otherwise you have mysteries
where the server isn't running and no-one knows why... until they discover a division by zero
error weeks later and realise it had exited on SIGFPE)

The real frustration isn't that Ctrl-C doesn't work, but that nothing works, and you've fixed
that. Having Ctrl-C be effective in such circumstances most of the time is merely a welcome
bonus. Similarly making these processes able to be killed by the OOM killer is also a bonus.

Is this an example of genuine innovation from Linux (even if it is one that most people won't
understand) ? Or is it copied from some other Unix which I'm not familiar with ?

^C vs SIGKILL

Posted Apr 21, 2008 11:52 UTC (Mon) by willy (subscriber, #9762) [Link]

I think you only find it acceptable because it's such a huge improvement over what went before
;-)

This idea, as far as I'm aware, is the product of Linus' Big Brain back in 2002.  The strange
thing is that nobody bothered to do it before now.