On Mon, Jun 2, 2008 at 11:20 AM, Alan Cox wrote: > On Mon, 02 Jun 2008 18:31:34 +0930 > David Newall wrote: > >> Alan Cox wrote: >> > Not really. The task would get suspended if it attempted to change the >> > tty settings while not being session leader. This is part of the POSIX >> > and BSD job control. >> >> I haven't heard about this new restriction, but it begs the observation >> that stty, when forked from a shell (the usual case), is never a session >> leader. > > Sorry I mean part of the current session. I was thinking about the > specific case of bash or the ssh->bash setup where the question would be > whether the shell was session leader. > > Someone who can dup this needs to instrument it in tty_ioctl really. Hi, I have written a short test program that seems to reproduce it for me (see attachment), even though the original su/stty stuff wouldn't. Basically, the strace shows this: ioctl(0, SNDCTL_TMR_START or TCSETS, {B38400 opost isig icanon echo ...}) = ? ERESTARTSYS (To be restarted) --- SIGTTOU (Stopped (tty output)) @ 0 (0) --- --- SIGTTOU (Stopped (tty output)) @ 0 (0) --- ioctl(0, SNDCTL_TMR_START or TCSETS, {B38400 opost isig icanon echo ...}) = ? ERESTARTSYS (To be restarted) --- SIGTTOU (Stopped (tty output)) @ 0 (0) --- --- SIGTTOU (Stopped (tty output)) @ 0 (0) --- ... (repeating) The exact code path triggering this seems to be: tcsetattr() -> ioctl(TCSETS) -> set_termios() -> tty_check_change() This is on a 2.6.24.5-85.fc8 kernel. I don't know what's wrong, but I hope this helps. Vegard -- "The animistic metaphor of the bug that maliciously sneaked in while the programmer was not looking is intellectually dishonest as it disguises that the error is the programmer's own creation." -- E. W. Dijkstra, EWD1036