Thomas Dickey, le Mon 24 Mar 2008 15:17:57 -0400, a écrit : > On Mon, Mar 24, 2008 at 02:31:39PM +0000, Samuel Thibault wrote: > > `If fildes refers to the master side of a pseudo-terminal, and this > > is the last close, a SIGHUP signal shall be sent to the controlling > > process, if any, for which the slave side of the pseudo-terminal is the > > controlling terminal.' > > > > and then in exit() of the controlling process: > > > > `If the process is a controlling process, the SIGHUP signal shall be > > sent to each process in the foreground process group of the controlling > > terminal belonging to the calling process.' > > But if xterm is doing this also (presumably for a long-forgotten > system which needed it), then it's still doing what the kernel is > expected to do - just redundant. (Bear in mind that this chunk of > xterm's been as-is for a long time - it's at least as old as X11R5 in > 1993).
Oops, sorry, in my previous mail I was wrong: xterm doesn't send SIGHUP to the foreground group, but just to the process group in has started, i.e. bash, just like the kernel would indeed (since that's the controlling process), so that's indeed a bit redundant, but keeping it shouldn't do any harm. And it is indeed possibly needed for some odd systems, on which rxvt not doing it would conversely have other troubles (SUS's exit() page talks about 4.2 BSD). > > but it doesn't tell about nother group, which then loose their > > controlling terminal. That is actually expected: when for instance > > in zsh I run "foo &" and then call disown, I expect foo to continue > > outputting data in the terminal. And if I close the terminal, I'd > > expect it to still continue, even if it lost its controlling terminal. > > But then foo should of course handle EOF properly. > > > > The problem here is that even when it is unable to terminate the > > foreground job itself, bash orphans it, i.e. it basically disowns it, > > and thus of course the kernel is not supposed to kill it. > > Is that because xterm kills the process group, or because bash isn't > handling the sudo'ed group as one would expect? Oops, sorry, it _does_ happen with rxvt sometimes too. Be it xterm or the kernel (in the case of rxvt) that sends SIGHUP to bash, the result is the same: bash tries to propagate it, fails, disowns, and when bash exits the kernel hence doesn't SIGHUP the sudo'ed group. That said, sometimes there is no problem: when the pty gets closed early, bash gets ioctl(255, TIOCSPGRP, [5779]) = -1 ENOTTY (Inappropriate ioctl for device) when it tries to disown the groups it has launched, and in that case the kernel will SIGHUP the sudo'ed group, since not only bash failed to kill it, but it also failed to disown it. So xterm is really not at fault here, it's bash that needs a fix. Samuel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
