Peter T. Breuer wrote:
> I'll add that a little playing with ps -o pid,ppid,pgid,sid tells me
> that
>
> 1) the session leader is the shell run BY an xterm

Hmmm.. I think maybe so.

But it's not attached to a tty in this case anyway, so that couldn't be the
source. Let me check: Yes, the xterm sends the SIGHUP to the shell (used
strace to monitor) when it dies. But it doesn't send it to any of the
other processes. Doing a quick test, invoking a new bash, invoking a bg
process, exiting shell, the process lives. Sending a SIGHUP causes the
shell to SIGHUP the bg process. This doesn't really change anything below,
though, it's just filling in a hole.

> 2) the xterm belongs to the same session as the shell it is run FROM.

Yes.

> Ditto process group, as far as I can see.

....not on my computer? Don't know why. (Doesn't matter.)

> So when you fork a process (i.e. in background) from a foreground
> process in a shell within an xterm, it should have the process group and
> the session group of the shell, which the shell leads.
>
> When its parent dies and control returns to the shell (prompt), then the
> surviving process is inherited by init and its parent changes to 1,
> while its process group remains that of the (dead) parent that launched
> it. Its session group remains that of the shell.

I think so too. yes.

>
> Its session leader has not died and so it should not and does not get
> HUP at that point.
>
> If now you kill the xterm (or the shell), then the shell dies and
>
> A) IF it is set to send sighup to children does so
> (which does not include the process inherited by init!)


> B) sighup is sent to the process group of the shell
> (which doesn't include the process you forked).


Sounds good to me.

> So I don't see how one should ever expect that such a process would die.
>
> Usually anyway when forking a daemon process one takes pains to set its
> process group away from what it was so that it won't be associated with
> the tty it was launched from, and won't receive signals from it and
> won't block on input or output from/to it.
>
>
> Peter

Nice! It makes sense and everything. I have to muse on it a little more, but
that sounds logical to me.

Jon.
-- * Does the walker choose the path, or does the path choose the walker?
(fr. Sabriel) * --