Take the 2-minute tour ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems.. It's 100% free, no registration required.

I have a strange behavior on my system.

When I invoke a command in the shell (bash version 4.2.45(1)-release), say top or cat, the running program (the process) does not respond to Ctrl+C. I even tried to run kill -2 <pid> and kill -15 <pid>, but it didn't help. However, I can kill processes with SIGKILL.

I own the process, I even tried to send a signal to the process (signals 2 and 15) as root but it did not respond. I can quit top if I press q.

Any ideas about the problem? Or any hint to troubleshoot it?

UPDATE 1

cat and top were just examples. All processes have the same behavior. I tried to write a simple program to sleep only (without signal handler) and I had the same behavior.

UPDATE 2

I wrote a small program to sleep only. This time I installed signal handler to catch SIGTERM and SIGINT. When I invoked kill -15 <pid> (and so with -2), my program did not receive the signal!

I also updated the kernel to 3.11.10-100.fc18.i686 and still having the same problem.

share|improve this question
2  
Do you happen to be using the nVidia proprietary drivers? If so, you're seeing unix.stackexchange.com/questions/107331/… –  derobert Jan 17 at 0:41
    
@derobert true! the reason was the nvidia proprietary driver! can you please write a full answer to accept it. –  Maxwell S. Jan 17 at 19:45
1  
Added an answer. I guess this warrants enough explanation to not mark the question a duplicate (and to be clear, no, you were not expected to find the other question. This is a very confusing bug...) –  derobert Jan 17 at 19:57
add comment

2 Answers

up vote 5 down vote accepted

Recent versions of the nVidia proprietary drivers (possibly combined with other recent versions of libraries) have a bug which causes them to corrupt the signal mask.

You can look at signal masks like this:

anthony@Zia:~$ ps -eo blocked,pid,cmd | egrep -v '^0+ '
         BLOCKED   PID CMD
fffffffe7ffbfeff   605 udevd --daemon
0000000000000002  4052 /usr/lib/policykit-1/polkitd --no-debug
0000000000087007  4646 /usr/sbin/mysqld --basedir=/usr […]
0000000000010000 15508 bash

That's about what it should look like. If you run that on a system with the proprietary nVidia drivers, you'll see all kinds of crazy values for BLOCKED, for many of your programs—including, likely, all the misbehaving ones.

Note that signal masks are passed from parent to child through fork/exec, so once a parent process has a corrupt one, all the children it spawns from that point forward will, too.

See also my question After upgrade, X button in titlebar no longer closes xterm and various distro bugs you'll be able to find now, knowing which package to look at. You can modify the code in my answer to that question to reset the signal mask to none blocked (Elide sigaddset and change SIG_UNBLOCK to SIG_SETMASK).

share|improve this answer
add comment

I think this is the desired behavior from top: it exits only on a "q" command from the keyboard.

The code of top probably installs signal catcher functions, either with a signal() system call, or a sigaction() system call. My guess would be that when top periodically updates the screen, it has received a signal, possible from an alarm() system call or something like that.

Are you certain that cat doesn't exit on a control-C or control-\ ? Both of those key-chords usually generate SIGINT and SIGQUIT respectively. cat wouldn't seem to benefit from recovering from either of those two signals.

One way to check what your tty driver thinks are the key-chords for SIGINT and SIGQUIT:

stty -a

On my machine it says something like:

speed 38400 baud; rows 24; columns 80; line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>;
eol2 = <undef>; swtch = <undef>; 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 -cdtrdsr
-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

The "intr = ^C" and "quit = ^\" mean "Send SIGINT to current foreground process on Control-C" and "Send SIGQUIT to current foreground process on Control-backslash". Did those two get changed somehow?

You might have your shell set to trap signals. In zsh and bash, the command:

trap "" INT

keeps control-C (in the same xterm) from killing a subsequent invocation of cat. But that "trap" doesn't keep a kill -QUIT from causing the cat process to exit. Nevertheless, you should check your bash or zsh or ksh dot files for trap "" INT invocations.

You don't mention what kernel version, what distro and what shell you're using. Mention of those things might get you a better answer.

share|improve this answer
    
Thank you for your answer. cat and top is just examples. all processes do the same behavior. i tried to write a simple program to sleep only ( without signal handler) and i had the same behavior. –  Maxwell S. Jan 16 at 23:26
    
@MaxwellS. - see edits. Maybe your keyboard/tty settings are messed up. –  Bruce Ediger Jan 16 at 23:34
    
i think the tty driver is okay intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; please note that i also invoked kill program to send signals –  Maxwell S. Jan 16 at 23:41
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.