![Ctrl + c 对 Linux 上的某些应用程序不起作用](https://linux22.com/image/532819/Ctrl%20%2B%20c%20%E5%AF%B9%20Linux%20%E4%B8%8A%E7%9A%84%E6%9F%90%E4%BA%9B%E5%BA%94%E7%94%A8%E7%A8%8B%E5%BA%8F%E4%B8%8D%E8%B5%B7%E4%BD%9C%E7%94%A8.png)
这是一个非常奇怪的问题,但在新系统(Fedora,Ubuntu)上,ctrl + c 对某些工具没有效果:
如果我执行 yum list,它会运行近一分钟,我无法使用 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
我尚未找到该问题的描述,如果有人能提供一些帮助我将不胜感激。
提前致谢。
答案1
有些应用程序会SIGINT
因为与其他库的奇怪交互而陷入困境。您可以尝试向它们发送一个SIGQUIT
(通过Ctrl\您的输出给出的stty
)。
答案2
SIGINT
正如 Ignacio 所说,有些应用程序只是进行捕获,其他应用程序则捕获所有键盘输入。
如果 Cc 不起作用,您可以尝试前面提到的 C-\,如果这不起作用,那么只需尝试后台进程:Cz。然后使用以下命令终止它kill -s SIGKILL <pid>
答案3
这是 yum 的一个错误。似乎越来越多的 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
这是一个坏习惯。
答案4
这通常发生在应用程序处于无法响应信号的状态,因为它无法从 CPU 调度程序队列恢复运行时。一个很好的例子是当应用程序挂起等待阻塞操作(主线程中的同步磁盘 I/O、交换输入/输出、阻塞网络 I/O 等)时。鉴于这是 yum,我猜是它连接到存储库/镜像列表配置中定义的一个或多个源时超时,但它很可能是访问其缓存、RPM 数据库(包括 BDB 损坏)或任何其他东西的磁盘 I/O 问题。
使用任意应用程序测试此行为的一个好方法是:硬挂载 NFS 共享,然后将 NFS 服务器脱机,然后尝试使用任何试图打开该目录的程序(find 或 /bin/ls 就是很好的例子)。在等待内核确定共享出了什么问题时,它不会对 SIGKILL 以外的任何消息做出响应。