12

我想知道为什么我在 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。

4

4 回答 4

20

这里的区别确实是干预过程。当您关闭终端窗口时，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）。 孤儿进程（在 wikipedia 上）有更多关于它的信息，另请参阅Zombie 进程了解一些额外的技术细节。

于 2009-09-23T04:15:35.957 回答
8

已经在运行进程？

^z
bg
拒绝 %<jobid>

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

nohup 脚本.sh &

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

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

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

或者

使用“屏幕”

于 2010-02-17T13:40:09.207 回答
3

尝试“nohup cmd args ...”

于 2009-09-23T03:52:36.780 回答
0

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

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

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

  • “脚本”不再是父级，并且 sleep 是 init 的孤儿（在 pstree 中很好地显示）
  • 您从中启动脚本的 bash shell 不再有基础作业

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

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

希望这可以帮助

于 2013-11-25T21:43:58.197 回答