Question

在使用redhat中的旧脚本时，我遇到了像

这样的行

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

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

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

Answer 1

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

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

在一个普通的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 -c像nohup一样工作吗？

1 个答案: