经过与同事长时间的讨论后问这个问题，我真的很想在这里澄清一下。
我启动一个后台进程，可以通过在命令行中追加“ & ”，或者通过CTRL-Z停止并使用“ bg ”在后台恢复。 然后我退出。
怎么了？
我们确信它应该被SIGHUP杀死，但是这并没有发生。 当再次login时，该过程高兴地运行，并且pstree显示它被init “采纳”。
这是预期的行为？
但是，如果是这样， nohup命令的目的是什么？ 看起来这个过程不会被杀死，无论有没有…
一些更多细节：
nohup和/或& ; 然后用CTRL-Z暂停，然后用bg重新开始。 exit ”命令）。 scp文件的复制操作。 pstree显示进程正在运行并且是initsubprocess。 要更清楚地说明问题：将背景（使用&或bg ）放到一个进程忽略SIGHUP ，就像nohup命令一样？
我尝试手动发送一个SIGHUP scp ：它退出，所以它绝对不会忽略信号。
然后我再次尝试启动它，把它放在后台并注销： init被“采纳”并继续运行，并且在重新login时发现它。
我现在很困惑。 看起来没有SIGHUP被发送在所有upong注销。
find答案。
对于BASH，这取决于huponexit shell选项，可以使用内置的shopt命令查看和/或设置huponexit shell选项。
看起来这个选项默认是closures的，至less在基于RedHat的系统上。
有关BASH手册页的更多信息：
收到SIGHUP后，shell会默认退出。 在退出之前，交互式shell将SIGHUP重新发送到所有正在运行或停止的作业。 停止的工作发送SIGCONT，以确保他们收到SIGHUP。 为了防止shell将信号发送到特定的作业，应该使用disown内build函数（请参阅下面的SHELL BUILTIN COMMANDS）将其从作业表中删除，或者使用disown -h标记为不接收SIGHUP。
如果已经使用shopt设置了huponexit shell选项，则当交互式loginshell退出时，bash将向所有作业发送SIGHUP。
我同意华纳，只是想补充说，你可以保持壳发送SIGHUP与内置的“disown”命令。 bash手册页包含一个很好的描述。
您可以使用命令nohup来启动命令并将输出redirect到nohup输出文件。 从nohup手册页：
nohup - run a command immune to hangups, with output to a non-tty
另一个选项是使用屏幕命令。 使用屏幕的好处是您可以稍后重新连接到该过程。
当你将一个进程分到后台时，它仍然是执行它的shell的subprocess。
在shell下运行的所有subprocess在退出时都会发送一个SIGHUP。 性能稍有不同，具体情况详见bash的manpage。 其他炮弹可能有类似的描述。
Apache和其他守护进程，通常在SIGHUP上重新加载configuration。 用户空间实用程序经常死亡 与信号相关的应用性能对于应用来说可能是独一无二的
这个过程是什么？ 在之前的张贴1中描述的performance是准确的。
某些脚本函数和进程可以捕获信号。 而循环可以疯狂逃跑。
看到：
SSH会话丢失 – 命令是否继续执行？
在下午4:22编辑1
从bash的manpage：
The shell exits by default upon receipt of a SIGHUP. Before exiting, an interactive shell resends the SIGHUP to all jobs, running or topped.
最初的研究1显示OpenSSH可能会忽略SIGHUP，也许更多的信号。
如果您没有通过像screen这样的工具来启动命令，那么当会话结束时，所有与该会话相关联的任务/任务也是如此。