Sign up ×
Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

It is a really weird problem, but on new systems(Fedora, Ubuntu) ctrl+c has no effect for certain tools:

if I execute yum list which runs for almost a minute I can't interrupt to run with ctrl+c

$time yum list >/dev/null

The command execution won't stop.

However to interrupt find is possible.

$ time find / >/dev/null 2>&1

real    0m0.741s
user    0m0.033s
sys     0m0.124s

I am curious what is causing this.

I have to following settings:

$ stty -a
speed 38400 baud; rows 36; columns 158; 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
-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

I couldn't find the description of the problem yet, I appreciate if somebody would be that kind to shed some light.

Thanks in advance.

share|improve this question
Which shell (and version)? Does it do this if you're not running time? – Dennis Williamson Dec 11 '10 at 14:56
Dennis, this is not time related, I can repeat it wo/ time same story. It seems it is a yum bug. – Istvan Dec 11 '10 at 15:15

6 Answers 6

Actually, rpmlib, used by yum, is grabbing and ignoring the ctrl-c signal handler. There's only so much can be done about this at yum's level. It's annoying, but I'm not sure it's worth getting all worked up about. Newer and newer versions of Fedora have successfully improved the handling of this, to the point where yum under Rawhide (which will become F15) does this for your test case:

$ time yum list >/dev/null
^CTraceback (most recent call last):
  File "/usr/lib64/python2.7/", line 553, in <module>
  File "/usr/lib64/python2.7/", line 544, in main
  File "/usr/lib64/python2.7/", line 500, in execsitecustomize
    import sitecustomize

real    0m0.164s
user    0m0.081s
sys     0m0.073s

It still will not let you interrupt changes to the RPM database with SIGINT, which is hard to really argue with.

share|improve this answer

Some applications just trap SIGINT as Ignacio mentioned, others capture all keyboard input.

If C-c doesn't work, you may try the already mentioned C-\ and if this doesn't work, then just try to background the process: C-z. and then kill it with kill -s SIGKILL <pid>

share|improve this answer
Hey, I guess kill -9 is not really a viable solution just to interrupt the running. (sockets left open, temporary files remaining etc.) – Istvan Dec 11 '10 at 14:23
@l1x: Does it respond to kill -SIGTERM? – Dennis Williamson Dec 11 '10 at 14:55
$ kill -15 1761 [1]+ Terminated time yum list > /dev/null it does – Istvan Dec 11 '10 at 15:13
well, if an app doesn't respond to SIGINT and SIGQUIT then it probably won't respond to SIGTERM, but it won't hurt trying out. – Hubert Kario Dec 12 '10 at 0:19
Yeah it is possible to kill it with SIGTERM, it is just a bug in signal handling. – Istvan Dec 12 '10 at 11:20

Definitely related to signal handling in the command you're calling. See a number of open yum bugs around the handling:

Red Hat Bugzilla – Bug List

Seems like Ctrl-C (SIGINT) might have been used to control other behavior (skipping to the next mirror) rather than the usual intention (killing the process).

Re: why SIGQUIT doesn't seem to do anything useful -- there may not be a defined handler.

share|improve this answer
Thank you sir. I opened a new bug report myself as well. I am just wondering how is it possible that those folks commenting on this think it is not a bug... – Istvan Dec 11 '10 at 23:36
Well it's not a bug if someone defined a handler specifically for the purpose of doing something else. But from the other reports, it seems like the behavior was supposed to be "one SIGINT to skip a mirror, two in rapid succession to cancel". – medina Dec 19 '10 at 3:11

This usually happens when the application is in a state where it's not actually able to respond to signals because it's not able to resume running from the CPU scheduler queue. A good example is when the application is hung waiting for a blocking operation (synchronous disk I/O in the main thread, swap in/out, blocking network I/O, etc.) Given that this is yum, I'm guessing that it's timing out connecting to one or more of the sources defined in your repository/mirrorlist configs, but it could easily be a disk I/O issue accessing its caches, the RPM database (including BDB corruption), or any number of other things.

A good way to test behavior this with any arbitrary application: hard-mount an NFS share, then pull the NFS server offline, then try to use any program that tries to open that directory (find or /bin/ls are good examples). It won't respond to anything beyond a SIGKILL while it waits for the kernel to figure out what's up with the share.

share|improve this answer
Well if it was working for 30 years in applications like find, grep, cat, etc. your explanation is incorrect. This is just a way of programming which is not desired. – Istvan Dec 11 '10 at 16:09
You should reread the second part of my answer in which I explain just how to test this behavior with exactly those utilities. – jgoldschrafe Dec 11 '10 at 17:47
up vote -1 down vote accepted

This is a yum bug. It seems there are more and more linux developers think it is a good idea to ignore standard signal handling and make their app to not react to standard signals.

man 7 signal

   Standard Signals
       Linux  supports the standard signals listed below.  Several signal numbers are architecture-dependent, as indicated in the "Value" col-
       umn.  (Where three values are given, the first one is usually valid for alpha and sparc, the middle one for ix86, ia64, ppc, s390,  arm
       and sh, and the last one for mips.  A - denotes that a signal is absent on the corresponding architecture.)

       First the signals described in the original POSIX.1-1990 standard.

       Signal     Value     Action   Comment
       SIGHUP        1       Term    Hangup detected on controlling terminal
                                     or death of controlling process
       SIGINT        2       Term    Interrupt from keyboard
       SIGQUIT       3       Core    Quit from keyboard
       SIGILL        4       Core    Illegal Instruction
       SIGABRT       6       Core    Abort signal from abort(3)
       SIGFPE        8       Core    Floating point exception
       SIGKILL       9       Term    Kill signal
       SIGSEGV      11       Core    Invalid memory reference
       SIGPIPE      13       Term    Broken pipe: write to pipe with no
       SIGALRM      14       Term    Timer signal from alarm(2)
       SIGTERM      15       Term    Termination signal
       SIGUSR1   30,10,16    Term    User-defined signal 1
       SIGUSR2   31,12,17    Term    User-defined signal 2
       SIGCHLD   20,17,18    Ign     Child stopped or terminated
       SIGCONT   19,18,25    Cont    Continue if stopped
       SIGSTOP   17,19,23    Stop    Stop process
       SIGTSTP   18,20,24    Stop    Stop typed at tty
       SIGTTIN   21,21,26    Stop    tty input for background process
       SIGTTOU   22,22,27    Stop    tty output for background process

This is a bad habit.

share|improve this answer
When you're dealing with anything database-oriented, you must trap any signals that could cause the program to terminate abnormally, leaving the database in an inconsistent state, and try to close the database gracefully. This is not bad design; this is common-sense. These programs will still respond to SIGKILL exactly as you would expect if SIGINT/SIGTERM doesn't work. – jgoldschrafe Dec 11 '10 at 16:01
How is executing "yum list" database-oriented? – Istvan Dec 11 '10 at 16:10
Yum operates on the rpmdb, the database for the RPM subsystem. – Scott Pack Dec 11 '10 at 17:27
So you say reading a database is uninterruptible, right. My only question would be in this case, how is it possible to terminate the program with signal 15. – Istvan Dec 11 '10 at 23:33
It's possible but will probably corrupt your RPM database. – mattdm Dec 12 '10 at 14:54

Some applications trap SIGINT because of strange interactions with other libraries. You can try sending them a SIGQUIT instead (via Ctrl\ as given by your stty output).

share|improve this answer
Hey, it doesn't work( ctrl + \ ) – Istvan Dec 11 '10 at 14:20

Your Answer


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.