ssh接続が失われた後、wgetが死ななかったのはなぜですか？

13

私はssh自分のサーバーにエドと走りwget -r -np zzz.aaa/bbb/ccc、それが仕事を始めました。それから（私の家での）インターネット接続が中断wgetされhup、ssh接続が失われたために端末が死んだためにそれがped されたのではないかと心配しました。しかし、その後ssh、サーバーに実行して、サーバーがまだ実行中で出力を入れてwget.logダウンロードしていることに気付きました。誰かが私にここで何が起こったのか説明してもらえますか？

これはps私に与えるものです：

PID   %CPU %MEM    VSZ    RSS TTY     STAT START   TIME COMMAND
32283  0.6 29.4 179824 147088 ?       S    14:00   1:53 wget -r -np zzz.aaa/bbb/ccc

?の列での意味（疑問符）はtty？

— 湯島フクサイ
ソース

を実行している最新のシステムlogindでlogindは、ユーザーのログアウト時に、ユーザーに属するすべてのプロセスを強制終了（SIGTERM）するのがデフォルトの動作であることに注意してください。したがって、この動作はシステム固有です。

— ダニエル・プライデン

@Dan私のシステムはubuntu 16.04

— 湯島シフクサイ

2

Ubuntu 16.04はsystemd / logindシステムですが、Ubuntuのデフォルトのlogind.confは明示的に設定しますKillUserProcesses=no。

— ダニエル・プライデン

21

プログラム（およびスクリプト）は、などのいくつかを除いて、ほとんどの信号を無視することを選択できますKILL。HUP信号がキャッチされ、ソフトウェアがそうしたい場合は無視することができます。

これはからあるsrc/main.cのwget源（バージョン1.19.2）：

/* Hangup signal handler.  When wget receives SIGHUP or SIGUSR1, it
   will proceed operation as usual, trying to write into a log file.
   If that is impossible, the output will be turned off.  */

シグナルハンドラの少し下にインストールされます。

  /* Setup the signal handler to redirect output when hangup is
     received.  */
  if (signal(SIGHUP, SIG_IGN) != SIG_IGN)
    signal(SIGHUP, redirect_output_signal);

そのため、シグナルを無視してwgetいないように見えますが、出力をログファイルにリダイレクトして処理を続行することを選択します。HUP

コメントでリクエスト：質問の出力?のTTY列の意味はps、wgetプロセスが端末/ TTYに関連付けられなくなったことです。SSH接続がダウンすると、TTYはなくなりました。

— クサラナナンダ
ソース

1

の意味も追加すると便利だと思います。ttyで。

— ユカシマフクサイ

はい、これを難しい方法で学びました。sshがドロップしたときにすべてのプロセスが停止するわけではありません。正確な理由を知るのは良いことです。

— ダグ

2

または、画面を使用する習慣を付けて、HUP を使用しないようにします。

— ハーパー-モニカの復活

8

シンプル：でwget中止しませんSIGHUP。ただし、SIGTERMとSIGINTになります。

manページには何もありませんがSIGHUP、wgetプロセスに送信すると、ターミナルでこれを取得します：

# in a different terminal while wget is running (with PID 12345)
kill -HUP 12345
# in the wget terminal
SIGHUP received.
Redirecting output to 'wget-log'.

— ハウケ・レイジング
ソース

1

ありがとう。プロセスにkill -HUP pid送信SIGHUPする方法を示すコマンドを追加する方が良いと思います。

— ユカシマフクサイ