[lkml]   [2004]   [May]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: strange delays on console logouts (tty != 1)
    On Sat, May 01, 2004 at 02:46:17PM -0700, Chris Wedgwood wrote:
    > On Fri, Apr 30, 2004 at 09:53:51PM +0200, Jorge Bernal wrote:
    > I'm not sure who is to blame here, it looks like some tty's get into a
    > state that either init or the getty doesn't like and don't want to
    > come unstuck easily (stty sane > /dev/tty<foo> sometimes helps).
    > I need to get an init working as pid != 1 with debugging so I can
    > figure out what init thinks here. I've just been so short of time.

    I do not think that it is init...

    If I did analysis correct, problem is that:

    (1) agetty (at least from util-linux 2.12 from current debian unstable)
    opens /dev/console and calls VT_OPENQRY to find first unopened VT. I have
    no idea why it does this, especially as it causes problems when more than
    one agetty is started simultaneously. I cannot believe that there is
    no better way how to detect whether tty is in use or not (as comment
    in the agetty suggests). Even spawning fuser /dev/ttyX looks less racy
    to me. This race between different agetty starting in parallel is reason
    why some gettys are missing after bootup. As they all use 10 sec timeout it
    takes some time until all my 24 gettys come up.

    (2) tty hangup is scheduled for work_queue.

    (3) when you have bad luck then scheduled hangup work runs AFTER newly
    created agetty calls VT_OPENQRY, and you get an error that ttyX is already
    in use...

    When I just put /dev/ttyX instead of ttyX into /etc/inittab, problem
    disappears (as then VT_OPENQRY code in agetty is not triggered) and
    everything works as it should - except 'w', so I just disabled OPENQRY
    code in agetty instead as final solution.

    I think that we should concentrate on how is it possible that init can
    spawn agetty and agetty can parse whole /var/run/utmp, open /dev/console
    and issue VT_OPENQRY before work scheduled before init was even notified
    is done. It looks to me like that someone schedules some job on the
    workqueue although that job apparently deserves its own kernel thread
    due to time it takes.
    Best regards,
    Petr Vandrovec
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 14:02    [W:0.022 / U:65.272 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site