5

redhatで古いinitscriptを操作しているときに、次のような行に出くわしました。

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

nohupを使用していないので疑わしいようです。ただし、プログラムは正しく動作し、制御端末が終了しても実行を継続します。さらに調べてみると、コマンドが呼び出された端末が終了しても、たとえばコマンドbash -c 'sleep 1000&'が起動したままになっているように見えることがわかりました（これはnohupなしでは不可能だったはずです）。この動作を最新のubuntuで検証しました。

だから私の質問は、この動作はよく知られていますか？つまり、nohupを使用するのではなく、initスクリプトで使用できますか？それともbashのバグですか？

4

1 に答える 1

5

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.

于 2012-07-12T03:16:37.687 に答える