对于Linux上的某些应用程序,Ctrl + c不起作用

这是一个非常奇怪的问题,但在新系统上(Fedora,Ubuntu),ctrl + c对某些工具没有任何影响:

如果我执行yum列表运行几乎一分钟,我不能打断用ctrl + c运行

$time yum list >/dev/null ^C^C^C^C^C^C^C^C^C 

命令执行不会停止。

但是要中断查找是可能的。

 $ time find / >/dev/null 2>&1 ^C real 0m0.741s user 0m0.033s sys 0m0.124s 

我很好奇这是什么造成的。

我必须遵循以下设置:

 $ 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 

我还找不到这个问题的描述,我很感激有人会这么说。

提前致谢。

有些应用程序因为与其他库的奇怪交互而陷入SIGINT 。 你可以尝试发送一个SIGQUIT来代替(通过你的stty输出给出的Ctrl \ )。

绝对与您所调用的命令中的信号处理有关。 看到处理周围的一些开放的yum错误:

红帽Bugzilla – Bug列表

https://bugzilla.redhat.com/buglist.cgi?quicksearch=yum+Ctrl-C

似乎像Ctrl-C( SIGINT )可能被用来控制其他行为(跳到下一个镜像),而不是通常的意图(杀死进程)。

回复:为什么SIGQUIT似乎没有做任何有用的事情 – 可能没有定义的处理程序。

有些应用程序只是在Ignacio提到的SIGINT中捕获SIGINT ,其他的则捕获所有键盘input。

如果抄送不起作用,您可以尝试一下已经提到的C- \,如果这样做不起作用,那么只要尝试后面的过程:Cz。 然后用kill -s SIGKILL <pid>杀死它

这是一个百胜的错误。 似乎有越来越多的Linux开发人员认为忽略标准信号处理并使其应用程序不对标准信号作出反应是一个好主意。

男人7号信号

  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 readers 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 

这是一个坏习惯。

这通常发生在应用程序处于不能响应信号的状态,因为它无法从CPU调度程序队列中恢复运行。 一个很好的例子是当应用程序挂起等待一个阻塞操作(主线程中的同步磁盘I / O,交换进/出,阻塞networkingI / O等)。假设这是yum,我猜测它正在连接到你的repository / mirrorlist configs中定义的一个或多个源,但它可能很容易成为访问它的caching,RPM数据库(包括BDB损坏)的磁盘I / O问题,或任何其他事情。

使用任意应用程序testing行为的一个好方法是:硬装载NFS共享,然后将NFS服务器脱机,然后尝试使用任何试图打开该目录的程序(find或/ bin / ls都是很好的示例)。 它不会对SIGKILL以外的任何内容作出响应,而是等待内核找出共享内容。

实际上,yum使用的rpmlib抓取并忽略了ctrl-c信号处理程序。 在百胜的水平上,只有这么多的事情可以做到。 这很烦人,但我不确定是否值得所有的事情。 Fedora的更新和更新版本已经成功地改进了处理这个问题,在Rawhide(将会变成F15)的情况下,yum对你的testing用例是这样做的:

 $ time yum list >/dev/null ^CTraceback (most recent call last): File "/usr/lib64/python2.7/site.py", line 553, in <module> main() File "/usr/lib64/python2.7/site.py", line 544, in main execsitecustomize() File "/usr/lib64/python2.7/site.py", line 500, in execsitecustomize import sitecustomize KeyboardInterrupt real 0m0.164s user 0m0.081s sys 0m0.073s 

它仍然不会让你用SIGINT中断RPM数据库的变化,这是很难真正与之争论的。