Messages in this thread | | | Date | Tue, 17 Jun 2008 09:32:58 -0600 | From | Joe Peterson <> | Subject | Re: 2.6.25.3: su gets stuck for root |
| |
Alan Cox wrote: > This looks correct to me and in fact I see the behaviour you report on 2.6.23 > when running it. If I tell it to ignore SIGTTOU that also then behaves as > expected. > > If > your pgrp is not the pgrp of the tty > and you are not ignoring TTOU > and you are not orphaned (as a group) > > Then we are *supposed* to send you SIGTTOU and kick you back > into touch.
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
| |