ssh连接断开后，为什么我的wget没死？

13

我ssh到服务器上运行wget -r -np zzz.aaa/bbb/ccc，它开始工作。然后我的互联网连接（在我家里）被打断了，我担心那wget是hup因为ssh连接丢失而导致ping 终止了，所以终端已经死了。但是后来我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什么意思？

— yukashima huksay
source

请注意，在运行的现代系统上logind，默认行为logind是当用户注销时杀死（SIGTERM）属于该用户的所有进程。因此，此行为是系统特定的。

— Daniel Pryden

@Dan我的系统是Ubuntu 16.04

— yukashima huksay

2

我相信Ubuntu 16.04是systemd / logind系统，但是Ubuntu默认的logind.conf显式设置KillUserProcesses=no。

— Daniel Pryden

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消失了。

— 库萨兰达
source

1

我认为如果您还添加？的含义，将很有用。在tty。

— yukashima huksay

是的，这是很难学到的。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'.

— Hauke Laging
source

1

谢谢。我认为最好还添加kill -HUP pid命令来显示如何发送SIGHUP到进程。

— yukashima huksay