Re: bash sends SIGHUP to disowned children in non-interactive mode

[Chet Ramey]

On 12/28/11 1:44 PM, ck850@web.de wrote:
>    I'm experiencing some strange behaviour with bash and xterm or other
>    X-terminals.
>    I'm using bash in Debian stable (GNU bash, Version 4.1.5(1)-release
>    (i486-pc-linux-gnu)).
>    To reproduce this, write a simple script like this:
>    #!/bin/bash
>    (xclock &)
>    sleep 15
>    Then run it with xterm -e.
>    xclock is not a child of xterm or bash (PPID=1) because it was invoked
>    with "(xclock &)":
>    F S UID        PID  PPID  C PRI  NI ADDR SZ WCHAN  STIME TTY
>    TIME CMD
>    0 S turin    23318     1  0  80   0 -  2292 -      17:52 pts/1
>    00:00:00 xclock
>    Yet xclock closes when the script exits because it receives a SIGHUP.

It may receive a SIGHUP, but you haven't demonstrated that it's bash
sending the SIGHUP.  Since job control isn't enabled, it's most likely
that the SIGHUP xterm sends to the process group when you hit the close
button gets to xclock because it's in the same process group as bash.

Bash only sends SIGHUP to running jobs of an interactive login shell when
the `huponexit' option is set.  It will resend SIGHUP to running jobs
if they haven't been disowned, but the background-process-inside-a-subshell
business means xclock isn't a child process or job of the shell anyway.

You might strace the bash process that runs the script inside the xterm
to see what it does.

I traced an instance of both scripts (above and below) on an Ubuntu 10
system with bash-4.2.10 and didn't see any sign that bash sent a SIGHUP,
even when I used the close button on the xterm (in which case bash
received the SIGHUP).

>    Just strace the PID:
>    Process 23318 attached - interrupt to quit
>    restart_syscall(<... resuming interrupted call ...>) = ?
>    ERESTART_RESTARTBLOCK (To be restarted)
>    --- SIGHUP (Hangup) @ 0 (0) ---
>    Process 23318 detached
>    This should not happen or am I wrong?
>    If you change the header in the script to #!/bin/tcsh or #!/bin/csh
>    xclock does not receive a SIGHUP.

Because csh sets SIGHUP to SIG_IGN in asynchronous children.  Bash doesn't.

>    Therefore I assume the problem is with bash.
>    Same with disown:
>    #!/bin/bash
>    xclock &
>    disown -a
>    sleep 15
>    Changeing the header to "#!/bin/bash -i" doesn't make a difference
>    either.
>    If I execute the script in an interactive terminal and close the
>    terminal window with the "x" button after the script finished xclock
>    stays open.
>    No SIGHUP. Why is a HUP signal send in the other case? Any ideas? Am i
>    missing something?

I suspect that it's the difference between job control and no job control,
but without knowing exactly which process sent the SIGHUP there isn't
enough information to say for sure.

Chet
-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
                 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, ITS, CWRU    chet@case.edu    http://cnswww.cns.cwru.edu/~chet/