On Mon, Mar 24, 2008 at 02:31:39PM +0000, Samuel Thibault wrote: > Thomas Dickey, le Mon 24 Mar 2008 09:42:07 -0400, a écrit : > > On Mon, Mar 24, 2008 at 10:52:33AM +0000, Samuel Thibault wrote: > > > Hello, > > > > > > Please see Debian bug #416976 - top should really check for EOF > > > > I happened to notice it. > > > > > cloned into bugs #458984 powertop Should check for EOF > > > bug #458985 bash Should not end job control on SIGHUP > > > and bug #458986 ncurses Should check for EOF/EIO > > > for the whole story. In short, what happens is that xterm sends SIGHUP > > > when being closed, but that can't reach sudo'ed groups, and that poses > > > problem, while letting the kernel doing it may just work fine. > > > > I'm not sure there: if xterm sends a SIGHUP, I suppose the problem > > is that it may close some part early. But if it cannot reach the > > sudo'ed process groups, then it's not clear why the kernel wouldn't > > be doing this as well. > > > > Also, this sounds like it may be a Linux-specific fix. > > Mmm, SUS says that kernel should just send SIGHUP to the controlling > proces: in close()
ok - but I'm puzzled why it's an issue now, but wasn't reported before. > `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). > 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? -- Thomas E. Dickey http://invisible-island.net ftp://invisible-island.net
pgpDwXPYxjkiq.pgp
Description: PGP signature
