Question

while working with an old initscript in redhat, I came across the line like

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

It seemed to be suspicious in that it does not use nohup. However the program works correctly, and stays up running even if the controlling terminal is exited. Investigating further I found that a command e.g bash -c 'sleep 1000&' seems to stay up even if the terminal from which it is invoked is exited (which shouldn’t have been possible without nohup). I verified this behavior with latest ubuntu.

So my question is, is this behavior well known? that is, can I use it in my init script rather than using nohup? or is it a bug in bash?

Answer 1

This piqued my curiosity: does SIGHUP behave like it used to? The first clue comes from the bash man page on shopt:

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

On a vanilla Ubuntu 12.04 installation, huponexit defaults to “off” even for an interactive session. Being a empiricist, I wanted to see it in action:

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

Even with stdin and stdout bound to a tty, it never receives a signal upon shell exit, which agrees with the documentation. As expected, the process becomes a child of init, and the connections to the pty are closed.

Judging from its defaults, SIGHUP is not considered “interesting” to bash interactive sessions. However, as soon as you depend on this, you’ll find a counter-example, most likely at the worst possible time.