我做了一些测试;看起来如果这是在物理控制台或通过SSH完成并不重要,这也不仅仅发生在SCP上;我还用cat / dev / zero>测试了它.的/ dev / null的.行为完全相同：
>使用&在后台开始一个过程(或者在使用CTRL-Z和bg开始后将其置于后台);这是在不使用nohup的情况下完成的.
>注销.
>再次登录.
>这个过程仍然存在,运行愉快,现在是init的直接孩子.
如果发送SIGHUP,我可以确认SCP和CAT立即退出;我用kill -HUP测试了这个.
因此,看起来SoughUP在注销时不会被发送,至少对于后台进程(由于显而易见的原因无法使用前台进程进行测试).
这最初发生在VMware ESX 3.5的服务控制台(基于RedHat)上,但我能够在CentOS 5.4上完全复制它.
问题是,再次：在注销时,即使它们在后台运行,也不应该向进程发送SIGHUP？为什么这不会发生？
编辑
根据凯尔的回答,我用strace检查过.
正如我所期望的那样,当从发布它的shell注销时,该进程不会得到任何信号.使用服务器控制台和SSH时都会发生这种情况.
解决方法
对于BASH,这取决于huponexit shell选项,可以使用内置shopt命令查看和/或设置该选项.
默认情况下,此选项看起来是关闭的,至少在基于RedHat的系统上是这样.
有关BASH man page的更多信息：
The shell exits by default upon receipt of a SIGHUP. Before exiting,an interactive shell resends the SIGHUP to all jobs,running or stopped. Stopped jobs are sent SIGCONT to ensure that they receive the SIGHUP. To prevent the shell from sending the signal to a particular job,it should be removed from the jobs table with the disown builtin (see SHELL BUILTIN COMMANDS below) or marked to not receive SIGHUP using disown -h.
If the huponexit shell option has been set with shopt,bash sends a SIGHUP to all jobs when an interactive login shell exits.
