bash -c是否像nohup一样工作？

Question

在Redhat中使用旧的init脚本时，我遇到了以下这行代码：

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

它看起来可疑，因为它没有使用nohup。但是该程序可以正常运行，并且即使控制终端退出，也能保持运行状态。进一步调查后，我发现一个命令例如bash -c 'sleep 1000&'似乎即使从中调用的终端退出，也会保持运行状态（这应该不可能没有nohup）。我已经在最新的Ubuntu上验证了这种行为。

所以我的问题是，这种行为是否广为人知？也就是说，我是否可以在我的init脚本中使用它，而不是使用nohup？或者这是bash中的一个错误？

- Rahul Gopinath

---

Bash仅在交互式会话中进行作业控制（包括发送作业的SIGHUP信号）。 - jordanm

@jordanm 这是一个答案，为什么不把它发表出来呢？ - kojiro

正如我所想的那样。看起来这并不适用于所有的bash。 - msw

Answer 1

这引起了我的好奇心：SIGHUP 的行为是否像以前一样？第一个线索来自于 bash man 页面上的shopt：

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

在纯净的 Ubuntu 12.04 安装中，即使是交互式会话，huponexit 的默认值也为“off”。作为一个实证主义者，我想看到它的实际效果：

#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;
}

即使将标准输入和标准输出绑定到tty，它也不会在shell退出时接收到信号，这与文档一致。预期，该进程成为init的子进程，并且与pty的连接关闭。

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

- msw