为啥我退出 shell 时 unix 后台进程有时会死机？

Posted 2023-02-16

【中文标题】为啥我退出 shell 时 unix 后台进程有时会死机？

【英文标题】：Why do unix background processes sometimes die when I exit my shell?为什么我退出 shell 时 unix 后台进程有时会死机？

【发布时间】：2010-11-30 15:14:13

【问题描述】：

我想知道为什么我在 Bash shell 的后台进程中看到了不同的行为

案例一：使用Putty(SSH)登录Unix服务器

默认使用 csh shell 我改成了 bash shell 输入睡眠 2000 & 按回车

它给了我工作编号。现在我通过单击腻子窗口中的 x 终止了我的会话 现在打开另一个会话并尝试查找进程..进程死了。

案例2：案例1：使用Putty(SSH)登录Unix服务器 默认情况下它使用 csh shell

我改成了 bash shell vi mysleep.sh sleep 2000 并保存 mysleep.sh ./mysleep.sh

这里的区别是……我不是直接执行睡眠命令，而是将睡眠命令存储在一个文件中并执行该文件。

现在我通过单击腻子窗口中的 x 终止了我的会话 现在打开另一个会话并尝试查找进程..进程仍然存在

不知道为什么会这样。我认为即使在注销后我也需要在 bash 中执行 disown 才能运行该进程。

我在父进程 id 中看到的一个差异..在第二种情况下..sleep 2000 的父进程 id 变为 1。看起来只要 mysleep.sh 的进程死亡，内核就将父进程分配给 1 .

【参考方案1】：

试试“nohup cmd args...”

【参考方案2】：

这里的区别确实是干预过程。 当您关闭终端窗口时，HUP 信号（与 an0nymo0usc0ward 提到的“nohup”相关）被发送到其中运行的进程。接收 HUP 的默认操作是死亡 - 来自 signal(3) 手册页，

 No    Name         Default Action       Description
 1     SIGHUP       terminate process    terminal line hangup

在您的第一个示例中，睡眠进程直接接收到此 HUP 信号并死亡，因为它没有设置为执行任何其他操作。 （一些进程捕获 HUP 并使用它来执行一些操作，例如重新读取一些配置文件）

在第二个例子中，运行你的 shell 脚本的 shell 进程已经死掉了，所以 sleep 进程永远不会收到信号。在 UNIX 中，每个进程都必须有一个父进程，这是由于 wait(2) 系列调用的工作原理以及通常的进程的内部机制。因此，当父进程死亡时，内核将其作为寄养孩子提供给 init（如您所述，pid 为 1）。 Orphan process (on wikipedia) 有更多关于它的信息，另请参阅Zombie process 了解更多技术细节。

【参考方案3】：

已经在运行进程？

^z bg 拒绝 %<jobid>

新进程/脚本（在本地机器的控制台上）？

nohup script.sh &

新进程/脚本（在远程机器的控制台上）？

根据您的需要， 有两个选项[会有更多;-)]

ssh remotehost 'nohup /path/to/script.sh </dev/null > nohup.out 2>&1 &'

或

使用“屏幕”

【讨论】：

这不能回答 OP 的问题。

【参考方案4】：

Steven 的回答是正确的，但我想在这里再次强调棘手的部分：

=> 使用只在后台执行睡眠的 bash 脚本

这样做的效果是“脚本”几乎立即退出（因为它完成了所有命令）。但是，它确实在其生命周期内创建了一个子进程（睡眠）。这样做的效果是：

“脚本”不再是父级，并且 sleep 成为 init 的孤儿（在 pstree 中很好地显示）

您从中启动脚本的 bash shell 不再有基础作业

请注意，这一切都是在您执行脚本时发生的，与任何 ssh 注销/putty 关闭无关。

当您最终关闭 putty 会话时，bash 会收到“SIGHUP”，但不会将其转发给任何其他进程（因为没有剩余工作） 在另一种情况下，bash 确实还有一份工作，然后它将 SIGHUP 发送到该工作，导致它结束（如您所见）

希望对你有帮助