[lkml]   [2008]   [Jun]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: su gets stuck for root
    On Sat, Jun 14, 2008 at 3:49 AM, Joe Peterson <> 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:


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


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


    "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

     \ /
      Last update: 2008-06-14 09:47    [W:0.034 / U:14.556 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site