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() `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 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. Samuel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
