SIGINT and SIGTSTP ignored by most common applications

Question

After the last upgrade to my Fedora, a strange behaviour started occurring in X terminal applications. I can't seem to stop any process using Ctrl+C, it just results in printing ^C to the console. Similarly, Ctrl+Z prints ^Z and the process goes on. Both work well in non-graphical virtual consoles.

I checked stty -a and it seems perfectly normal:

speed 38400 baud; rows 24; columns 80; line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = M-^?; eol2 = M-^?;
swtch = M-^?; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W;
lnext = ^V; flush = ^O; min = 1; time = 0;
-parenb -parodd cs8 hupcl -cstopb cread -clocal -crtscts
-ignbrk brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr icrnl ixon -ixoff
-iuclc ixany imaxbel iutf8
opost -olcuc -ocrnl onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0
isig icanon iexten echo echoe echok -echonl -noflsh -xcase -tostop -echoprt
echoctl echoke

This is independent of the terminal (gnome-terminal, XFCE4 terminal, xterm). I later noticed that it may not be caused by the terminal at all: INT or TSTP sent directly to the respective process are ignored, too. This comprises various applications I used to terminate using Ctrl+C on a regular basis (and which often don't have any better means of exiting): cat, find, tail -f, java, ping, mplayer when stuck on a broken file...

Even bash ignores Ctrl+C when I want to break a command line I have been entering and then changed my mind (no ^C is printed in this case). I need to delete it character by character (of which there may be hundreds if filename completion has been used) or intentionally run the unwanted command. Strangely enough, vim does recognize Ctrl+C — just to say its "use :quit", of course.

This is extremely annoying and prevents me from working efficiently. Everything had been working until lately, maybe a week ago or so. I can not find any possible causes in Google, perhaps I'm trying wrong search terms or misidentifying the main problem. What could be it and how could I revert the standard behaviour, please?

Update

Ctrl+Z works sometimes. It seems that in the very first terminal I launch after logging in it stops the running command but stops working after that.

Answer 1

I would suspect your desktop environment. Which do you use?

NEW answer.

Something on the path from init to your shell sets SIGINT and SIGTSTP to be ignored. This is eventually inherited by your shell. You can use this small program to spawn any program with the signals reset to default.

#include <signal.h>

int main(int argc, char **argv)
{
    signal(SIGTSTP, SIG_DFL);
    signal(SIGINT, SIG_DFL);
    execvp(argv[1], argv+1);
}

Answer 2

For anyone who might face the same problem:

I have employed a variation of fstx's solution and it works well for me in all cases (nested logins, SSH, ...) right now.

A little utility needed to be written in C, compiled and put somewhere in the $PATH:

sig.c

#include <signal.h>
#include <unistd.h>

int main(int argc, char **argv)
{
    sigset_t mask;
    sigfillset(&mask);
    sigprocmask(SIG_UNBLOCK, &mask, NULL);
    return execvp(argv[1], argv+1);
}

Then this little check in the very beginning of .bashrc ensures that no signals are blocked:

if ( grep SigBlk /proc/self/status | grep -qv 00000 )
then
    exec sig $0 $@
fi

Answer 3

Here's workaround similar to those already provided. It doesn't require you to compile a special program, so some people may find it more convenient.

exec ksh -c 'exec $SHELL'

Install ksh with yum install ksh if you don't have it already.