☰

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

tag-icon • tag-icon ssh terminal wget signals
为什么我的 wget 在 ssh 连接丢失后没有死掉？

我ssh编辑到我的服务器并运行wget -r -np zzz.aaa/bbb/ccc，它开始工作。然后我的互联网连接（在我家里）被中断，我很担心假设已经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？

答案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 关联。当 SSH 连接断开时，TTY 就消失了。TTYpswget

答案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'.

相关内容