フォアグラウンドでアプリを起動し、CTRL+（次に停止）を押してZバックグラウンドにドロップします。再び動作させるためにコマンドを実行しましたbg %1（これはJOBSPECです）。
私はそれを再実行しようとしない理由が何であるかを考えましたkill -CONT <PID>。だから私はjobs -lPIDを取得するために走り、CONT信号と一緒にこのpidをkillと一緒に使用しました。
しかし、ショーは再び公開されませんでした！jobs -lCONTで終了しようとすると、実行中と報告されますが、実行中ではありません（灰色で表示されるため）。
このコマンドを使用してアプリケーションPIDを確認したpsところ、2つの同じコマンドが異なるPID（および状態Tl）を持っていることがわかりました。
その後、同じものを使って調べたところ、pstreeどちらも親プロセスに属することがわかりました。jobs -lバックグラウンドに配置されたプロセスは他のプログラムを起動しているように見えるため、親プロセスはリストされているプロセスとは異なります。他のプログラムが子プロセスを生成しているようです。
私が注目した内容を要約すると、次のようになります。
killプログラムを実行するには、親プロセスにCONTを送信します。親プロセスPIDが報告されたものとは異なります
jobs -l。つまり、CONT信号を送信しようとしているプロセスがjobs -l。CONT を親プロセスに送信すると、同じシグナルは子プロセスに適用されません。
bgプロセスを実行状態に戻し、すべての子プロセスの親プロセスにCONT信号を送信するには、このコマンドを使用します。
私の結論は正しいですか？その場合、このコマンドを使用すると、bg各関連プロセスにCONTを送信する時間が節約されます。これは正しいですか？
編集する私はコマンドラインから呼び出してバックグラウンドに配置する主なアプリケーションですgit difftool。私が言う他のアプリケーションはそれ自身で新しいサブキーを生成し、meldそれをgitの比較ツールとして設定しました。
ベストアンサー1
まず、jobs -l記載されているプロセスはありませんが、プロセスグループ（別名日）。各プロセスグループには、プロセスID（pid）が対応するプロセスグループID（pgid）と同じプロセスリーダーがあります。
リーダーだけでなく、プロセスグループ内のすべてのプロセスにシグナルを送信するには、killpgidに負の数を使用して呼び出す必要があります。 Kill(2) マンページではこれについて説明します。
pidが-1未満の場合、IDが-pidのプロセスグループ内のすべてのプロセスにsigが送信されます。
シェルでも同じ効果があります。
$ sh -c 'while echo -n 1; do sleep 1; done'
111^Z
[1]+ Stopped sh -c 'while echo -n 1; do sleep 1; done'
$ jobs -l
[1]+ 11046 Stopped sh -c 'while echo -n 1; do sleep 1; done'
$ kill -CONT 11046
<nothing>
$ kill -CONT -11046
$ 11111111...
今結論を下してください。
プログラムを実行するには、kill を使用して CONT を親プロセスに送信します。
正しい
親プロセスPIDは、jobs -lによって報告されたPIDとは異なります。つまり、CONT信号を送信する必要があるプロセスは、jobs -lを使用して見つけたプロセスとは異なります。
間違っています。同じpidで、pgidと同じです。
CONT を親プロセスに送信すると、同じシグナルは子プロセスに適用されません。
正しい
bgコマンドを使用してプロセスを実行状態に戻し、CONT信号を親プロセスとすべての子プロセスに送信します。
はいが、親プロセスと子プロセスの両方が同じプロセスグループにある場合にのみ適用されます。また、各プロセスに対して順番にkill（2）を呼び出すのではなく、pgid（=プロセスグループリーダーのpid）の負数を使用して一度だけ呼び出し、カーネルに依存して信号をすべてのプロセスにルーティングします。そのグループ。