web-dev-qa-db-ja.com

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

私は自分のサーバーにsshedして実行しましたwget -r -np zzz.aaa/bbb/cccそしてそれは働き始めました。次に、私の自宅でのインターネット接続が中断され、wget接続が失われたため端末が停止したため、hupがsshpedされたと想定して心配になりました。しかし、サーバーにsshedしたところ、サーバーがまだ実行中であり、出力を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の列の意味ですか？

sshterminalwgetsignals
13
yukashima huksay

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

これはwgetソースのsrc/main.cからのものです（バージョン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はignoringHUP信号ではないように見えますが、出力をログファイルにリダイレクトして処理を続行することを選択しています。

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

21
Kusalananda

シンプル：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'.
8
Hauke Laging