bash -c像nohup一样工作吗？

Question

在使用redhat中的旧脚本时,我遇到了类似的行

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

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

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

Answer 1

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

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对于打击交互式会话并不被认为是"有趣的".但是,只要您依赖于此,您就会找到一个反例,很可能是在最糟糕的时候.