为什么我的 wget 在 ssh 连接丢失后没有死？

Question

我ssh编辑到我的服务器并运行wget -r -np zzz.aaa/bbb/ccc它开始工作。然后我的Internet连接（我家）中断了，我开始担心假设wget已经hupPED因为ssh连接丢失，因此终端已经死了。但是后来我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？

Answer 1

程序（和脚本）可以选择忽略大多数信号，除了一些像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 消失了。

Answer 2

简单：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'.