☰

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

tag-icon • tag-icon linux ssh command-line-interface terminal
Ctrl + c 对 Linux 上的某些应用程序不起作用

这是一个非常奇怪的问题，但在新系统（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 以外的任何消息做出响应。

相关内容