Re: 2.6.25.3: su gets stuck for root

Vegard Nossum
2008-06-14T07:45:28Z

On Sat, Jun 14, 2008 at 3:49 AM, Joe Peterson <joe@skyrush.com> wrote:
> Vegard Nossum wrote:
>> I think knowing the pgrps of the above processes (there is possibly
>> one more involved, stty?) would be useful; try:
>>
>> $ ps -eo pid,pgrp,tpgid,user,args
>
> OK, I performed this test again (getting the su to hang), and here is
> the info:

[snip]

> scorpius ~ # ps -eo pid,pgrp,tpgid,user,args | grep 7036
> 6902 6902 7036 root /bin/login --
> 6922 6922 7036 root -bash
> 7036 7036 7036 foo su foo
> 7037 7037 7036 foo bash
> 7042 7037 7036 foo stty -ixany

So this clearly shows what's wrong; 7036 is the "controlling process"
group id. But only "su foo" is in this group, the bash and stty
processes have their own group, 7037.

On my own system, when I do "su", I get this:
2891 2891 2892 root su temp
2892 2892 2892 temp bash

...and here the "bash" process is in the right group, 2892, while "su"
is the one in the background!

Can you try to run strace on the su to see where things go wrong, i.e.

$ strace -f -e trace=process su foo

...and we're only interested in what happens up to the point where it
hangs. That should hopefully tell us which process is doing the wrong
thing. In either case, as Alan pointed out, this seems unlikely to be
a kernel problem.

[snip]

>> so can you please look for anything like that in your login scripts or
>> shell rc files?
>
> I do use stty in my .bashrc (that's why this happens), but I do not put
> it in the background.

Yeah, most likely the process that calls stty is first put in the
background itself (or never brought to the foreground?). But I don't
know why... when you get the trace, we can compare and find out where
it deviates.

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