☰

キャプチャされていないSIGINTを受信した後、プロセスは続行されます（ターミナルでCtrl-C）。

tag-icon • tag-icon linux process signals gnu-make
キャプチャされていないSIGINTを受信した後、プロセスは続行されます（ターミナルでCtrl-C）。

Ctrl-CCentos7の端末で実行されているいくつかのプロセスを中止しようとしています。一部は中断されますが、一部は中断されません。

問題のプロセスの1つ（Process-A）は、アドオンなしのGNU makefileです。一般的な単一ファイル make システムです。もう1つ（プロセスB）は、TCPソケットでリッスンするCアプリケーションです。

以下は、これらの問題のあるプロセスの一部を実行（およびシャットダウン）しながら観察したものです。

  • プロセスAは従わないCtrl-C。 strace -fで始まり、Ctrl-C押すと、straceが子プロセスから切り離されますトレース終了ただし、プロセスAはトレースログなしで実行されます（異常です）。
  • Ctrl-CProcess-Bはで始まるとstrace -fSIGINTを捕捉できず、期待どおりに終了します。
  • Process-BはCtrl-Cバックグラウンドで抑制されても、それを削除せずにSIGINT（）を外部に送信し、kill -s SIGINT PIDSIGTERMはそれを終了します。

追加の詳細：

  1. テストプログラムを使用して、私の端末がSIGINTをプロセスに送信していることを確認しました（テストプログラムは終了しました）。
  2. どちらのプロセスも手動で信号をキャプチャしませんでした。
  3. 同じ動作を観察するには、複数の端末アプリケーションを試してください。

これらのシグナルがどのようにカスケードされているのか、そしてここで何が欠けているのかを明確に理解する必要があります。この種の問題をデバッグする方法は？

アップデート1：

grep 'search_string'入力を待つためにgrepを実行してくださいSTDIN。これで閉じられませんCtrl-C。これが環境固有の問題かどうか疑問になり始めました。

アップデート2：

いくつかの作業の後、以下に示すソースRVMスクリプトが問題を引き起こすことが確認されました。

if [ -f ~/.rvm/scripts/rvm ]; then
  source ~/.rvm/scripts/rvm
  export PATH="$PATH:$HOME/.rvm/bin"
fi

答え1

Process-AはCtrl-Cで終了しませんが、straceは終了します（異常です）。

straceこれは信号処理ではなくProcess-A処理なので、まったく驚くべきことではありません。生成された信号は、control+cフォアグラウンドプロセスグループ内のすべてのプロセスに送信されます。端末他のモードでは、以下のテストケースには、straceとが含まれますperl。strace終了しますが、信号は無視され、プロセスは終了するまで実行され続けます。

% strace perl -E '$SIG{INT}="IGNORE";while(1){say $$;sleep 1}'
...
% 9520
9520
9520
kill9520
 9520
%

grep が STDIN からの入力を待つように grep 'search_string' を実行します。これでCtrl-Cを使用して閉じることができません。

これは、シェルの構成に問題があることを示します。grep親プロセス（この場合はシェル）から継承されたシグナルハンドラがある可能性があります。私blocksigこのケースを説明するスクリプト：

% grep asdf
^C
% blocksig grep asdf
^C^C^C^C^C^]^\zsh: quit       blocksig grep asdf
%

しかし、あなたの場合、これはblocksig親プロセスではなくシェルです。一般的なファイルを読み取らずに別のシェルに切り替えるか、シェルを起動するとrcどうなりますか？シェル構成にtrap設定、カスタム操作、またはジョブ監視構成がありますか？

関連情報