Vegard Nossum wrote:
quoted text
> 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!

Hmm.

quoted text
> 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.

OK, I attached this as a text file at the end.  But (*bummer*), using
strace makes it impossible to reproduce the hang (figures, and I believe
someone earlier in the thread also had this problem).

As for whether the kernel is at fault, not sure (i.e. does this hang
behavior implicate the kernel automatically or can a user-space process
cause itself such an issue?).  But I *do* see different behavior
depending on the kernel version.  There were a couple of git kernels in
which I could not reproduce it.  Still, if it is a race or something, it
might be that the conditions were just slightly perturbed.

I attached the strace log just in case it is of help.

					-Joe