OK, I am still baffled. I've thought of several different theories,
wondering if bash does not have the right parent process, how there
could be a race in the kernel or elsewhere, but as far as I can tell,
things are in order. Here's the ps -ax --forest output while hung:
6435 tty3 Ss 0:00 /bin/login --
7954 tty3 S 0:00 \_ -bash
7958 tty3 S+ 0:00 \_ su foo
7959 tty3 S 0:00 \_ bash
7964 tty3 T 0:00 \_ stty -ixany
I had logged into the tty as root (with shell set to bash), then su'd to
foo (with shell set to bash), so this tree makes sense. During the
sleep before the stty, sleep is under the final bash similar to the way
stty is while it is hung.
Note that the stty is a child of bash (which, BTW, sometimes appears as
"-su" instead - I am not clear on that), and they all lead back to the
original tty, which I gather is the session leader (or is it the "su"?).
Now, the debugging I did shows that the reason that tty_check_change()
returns an error is that the tty->pgrg != task_pgrp(current). The
former is the "su foo" process, and the latter is the bash child process.
So I guess that when it does work, they are the same process, but why
would they be the same (or not, as it were)? Does something happen
during bash startup that causes bash to become the session leader?
Please, please, someone who understands the mechanics better than I let
me know how I can explore this more deeply.
Thanks, Joe
--
