web-dev-qa-db-ja.com

Ctrl + cは、Linux上の特定のアプリケーションでは機能しません

これは本当に奇妙な問題ですが、新しいシステム（Fedora、Ubuntu）では、ctrl + cは特定のツールには影響しません。

ほぼ1分間実行されるyumlistを実行すると、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

問題の説明はまだ見つかりませんでした。誰かがそのような人に光を当ててくれたら幸いです。

前もって感謝します。

linuxsshcommand-line-interfaceterminal
2
Istvan

これは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

これは悪い習慣です。

1
Istvan

一部のアプリケーションは、他のライブラリとの奇妙な相互作用のためにSIGINTをトラップします。代わりにSIGQUITを送信してみてください（経由 Ctrl\stty出力で指定されたとおり）。

7
Ignacio Vazquez-Abrams

Ignacioが述べたように、一部のアプリケーションはSIGINTをトラップするだけで、他のアプリケーションはすべてのキーボード入力をキャプチャします。

C-cが機能しない場合は、すでに説明したC- \を試してみてください。これが機能しない場合は、プロセスをバックグラウンドで実行してみてください：C-z。そしてkill -s SIGKILL <pid>でそれを殺します

2
Hubert Kario

呼び出しているコマンドの信号処理に明確に関連しています。処理に関する未解決のyumバグの数を参照してください。

Red Hat Bugzilla –バグリスト

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

Ctrl-C（SIGINT）は、通常の意図（プロセスの強制終了）ではなく、他の動作（次のミラーへのスキップ）を制御するために使用された可能性があります。

Re：なぜSIGQUITは何の役にも立たないようです-定義されたハンドラーがないかもしれません。

1
medina

実際、yumが使用するrpmlibは、ctrl-cシグナルハンドラーを取得して無視しています。これについては、yumのレベルでできることはたくさんあります。面倒ですが、すべてを解決する価値があるかどうかはわかりません。 Fedoraの新しいバージョンは、これの処理を正常に改善し、Rawhide（F15になる）の下のyumがテストケースに対してこれを行うようになりました。

$ 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データベースへの変更を中断することはできません。

0
mattdm

これは通常、アプリケーションがCPUスケジューラキューから実行を再開できないために、実際にシグナルに応答できない状態にある場合に発生します。良い例は、アプリケーションがブロッキング操作（メインスレッドでの同期ディスクI/O、スワップイン/アウト、ブロッキングネットワークI/Oなど）を待ってハングしている場合です。これがyumであることを考えると、私はそれを推測していますリポジトリ/ミラーリスト構成で定義された1つ以上のソースへの接続がタイムアウトしますが、キャッシュ、RPMデータベース（BDBの破損を含む）、またはその他のさまざまなものにアクセスするディスクI/Oの問題である可能性があります。

任意のアプリケーションでこれの動作をテストする良い方法：NFS共有をハードマウントし、NFSサーバーをオフラインにして、そのディレクトリを開こうとするプログラムを使用してみてください（findまたは/ bin/lsが良い例です）。カーネルが共有の状態を把握するのを待つ間、SIGKILL以外には何も応答しません。

0
jgoldschrafe