From: Tobias Grundmann In kernel 2.6.10/kernel/signal.c sig_ignored() I found this comment: ... /* * Blocked signals are never ignored, since the * signal handler may change by the time it is * unblocked. */ if (sigismember(&t->blocked, sig)) return 0; ... so it seems this behaviour is intentional, but I don't understand it. Why should it matter if a signal handler may change while blocked, if it is ignored also, which is a user request? The machine im writing this mail on runs with the above lines commented out without any problems so far... All this resulted from problems a customer had with implementing a whole protocol-stack to a serially attached device in a signal-handler. After the handler ran (with SIG_IGN) there was always an extra SIGIO which triggered the handler again. Of course the real fix was to move the protocol-stack out of the handler but still it should have worked since it was a controlled environment (so there wasn't even a race between entering the handler and setting SIG_IGN). Oh and it worked for years under some realtime variant of hp-unix. The following patch fixes the IMHO incorrect behavior to silently ignore attempts to set SIG_IGN on blocked signals (i.e. while running in a signal handler). Signed-off-by: Andrew Morton --- 25-akpm/kernel/signal.c | 8 -------- 1 files changed, 8 deletions(-) diff -puN kernel/signal.c~enable-sig_ign-on-blocked-signals kernel/signal.c --- 25/kernel/signal.c~enable-sig_ign-on-blocked-signals 2005-03-20 16:15:16.000000000 -0800 +++ 25-akpm/kernel/signal.c 2005-03-20 16:15:16.000000000 -0800 @@ -162,14 +162,6 @@ static int sig_ignored(struct task_struc if (t->ptrace & PT_PTRACED) return 0; - /* - * Blocked signals are never ignored, since the - * signal handler may change by the time it is - * unblocked. - */ - if (sigismember(&t->blocked, sig)) - return 0; - /* Is it explicitly or implicitly ignored? */ handler = t->sighand->action[sig-1].sa.sa_handler; return handler == SIG_IGN || _