[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Chet Ramey
Subject: Re: bash sends SIGHUP to disowned children in non-interactive mode
Date: Wed, 28 Dec 2011 15:20:43 -0500
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:8.0) Gecko/20111105 Thunderbird/8.0

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 &)":
>    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.

``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/

reply via email to

[Prev in Thread] Current Thread [Next in Thread]