5

在 redhat 中使用旧的 initscript 时，我遇到了这样的问题

daemon --user $USER --pidfile $PIDFILE "cmd >>/var/log/cmd.log 2>&1 &"

它似乎很可疑，因为它不使用 nohup。但是，程序可以正常工作，即使退出控制终端也能保持运行。进一步调查我发现，bash -c 'sleep 1000&'即使退出了调用它的终端，例如命令似乎仍然存在（如果没有 nohup，这应该是不可能的）。我用最新的 ubuntu 验证了这种行为。

所以我的问题是，这种行为众所周知吗？也就是说，我可以在我的初始化脚本中使用它而不是使用 nohup 吗？或者它是bash中的一个错误？

4

1 回答 1

5

这激起了我的好奇心：SIGHUP 的行为是否像以前一样？第一条线索来自 bash 手册页shopt：

huponexit如果设置，bash 将在交互式登录 shell 退出时向所有作业发送 SIGHUP。

在 vanilla Ubuntu 12.04 安装中，即使对于交互式会话，huponexit 也默认为“关闭”。作为一名经验主义者，我希望看到它的实际应用：

#include <stdio.h>
#include <stdlib.h>
#include <signal.h>
#include <unistd.h>

void
hupped(int i)
{
    fprintf(stderr, "received SIGHUP 0x%x\n", i);
    exit(1);
}

int main(int argc,char * argv[])
{
    fprintf(stderr, "registering SIGHUP handler for PID %d\n", getpid());
    signal(SIGHUP, hupped);
    sleep(3600*5);
    return 0;
}

即使 stdin 和 stdout 绑定到 tty，它也不会在 shell 退出时收到信号，这与文档一致。正如预期的那样，该进程成为 init 的子进程，并且与 pty 的连接被关闭。

从它的默认值来看，SIGHUP 对于 bash 交互式会话来说并不被认为是“有趣的”。然而，一旦你依赖它，你就会找到一个反例，很可能是在最糟糕的时候。

于 2012-07-12T03:16:37.687 回答