On 4 September 2008, Chet Ramey <[EMAIL PROTECTED]> wrote:
> > Description:
> > Regradless of the huponexit setting ('shopt -s huponexit' doesn't
> > help) bash does not send SIGHUP to its children when it receives one
> > itself. Previous version of bash 3.1.17 was behaving properly
> > even with huponexit set to off
> >
> > Repeat-By:
> > launch rxvt, launch mc then close the rxvt window ->
> > mc is still running with CPU to 100% (this is because
> > mc tries to read from stdin while receiving EOF)
> > Closing rxvt sends SIGHUP to bash but bash doesn't send
> > SIGHUP to its children
>
> Can you verify using a system call tracer that bash is not sending the SIGHUP?
> The default bash SIGHUP signal handler resends SIGHUP to all jobs, running or
> stopped, before exiting.
Hi Chet,
I did verify that with strace:
bash strace is:
29939 read(3, 0xbfc26ba4, 128) = ? ERESTARTSYS (To be restarted)
29939 --- SIGHUP (Hangup) @ 0 (0) ---
29939 --- SIGCONT (Continued) @ 0 (0) ---
29939 sigreturn() = ? (mask now [])
29939 read(3, <unfinished ...>
while mc tries to read in an infinite loop:
29948 read(0, ""..., 1) = 0
29948 select(1024, [0 4], NULL, NULL, {0, 100000}) = 1 (in [0], left {0,
100000})
29948 select(1024, [0 4], NULL, NULL, NULL) = 1 (in [0])
29948 select(1024, [0 4], NULL, NULL, {0, 100000}) = 1 (in [0], left {0,
100000})
29948 select(1024, [0 4], NULL, NULL, NULL) = 1 (in [0])
There is no signal passed to mc at all.
--
Regards,
Emil
--
I had one of them wooden computers once. Wooden keyboard,
wooden monitor, wooden CPU... only one problem: it wooden work.
