[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: bash sends SIGHUP to disowned children in non-interactive mode
From: |
Philip |
Subject: |
Re: bash sends SIGHUP to disowned children in non-interactive mode |
Date: |
Wed, 28 Dec 2011 23:57:14 +0100 |
> 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.
Yes that why used that background-process-inside-a-subshell because I thought
is was a good way to make sure that it won't be a job of the shell.
I didn't get anywhere with the strace yet but figured out (thanks to you and
Greg)
that I get a different behavior with job control enabled.
So let's take these two scripts, clock1.sh and clock2.sh.
I know it sounds boring but please bear with me.
-------------
#!/bin/bash
set -m
xclock &
sleep 2
--------------
#!/bin/bash -i
xclock &
sleep 2
--------------
I run them with: xterm -hold -e './clock1.sh'
the -hold keeps the xterm window open after the scripts finish.
The first script works fine, xclock stays. I don't even have to
disown. The second script, xclock appears and disappears after
2 seconds. Received a SIGHUP when the script ended. The xterm
window is still there because of the -hold parameter.
I get the exact same behavior if I use "(xclock &)" instead.
So without job control bash might (I know, we don't know for sure)
send the SIGHUP to all processes started in the shell, whether child
by definition or not?
Shouldn't the -i flag enable job control by the way?
Regards,
Philip