bash -c像nohup一样工作吗？

发布时间：2020-12-15 21:41:54 所属栏目：安全来源：网络整理

导读：在使用redhat中的旧脚本时,我遇到了类似的行守护进程–user $USER –pidfile $PIDFILE“cmd /var/log/cmd.log 2 1” 它似乎是可疑的,因为它不使用nohup.但是程序正常工作,即使退出控制终端也能保持运行.进一步调查我发现一个命令,例如bash -c’睡眠1000’即

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

守护进程–user $USER –pidfile $PIDFILE“cmd>> /var/log/cmd.log 2>& 1&”

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

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

解决方法

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

huponexit If set,bash will send SIGHUP to all jobs when an interactive login shell exits.

在一个普通的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%xn",i);
    exit(1);
}

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

即使stdin和stdout绑定到tty,它也不会在shell退出时收到信号,这与文档一致.正如所料,该进程成为init的子进程,并且关闭了与pty的连接.

从其默认值来看,SIGHUP对于打击交互式会话并不被认为是“有趣的”.但是,只要您依赖于此,您就会找到一个反例,很可能是在最糟糕的时候.

（编辑：李大同）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!