init/getty/login issue

[Denys Vlasenko]

On Monday 24 May 2010 02:39, John Williams wrote:
> On Sun, May 23, 2010 at 5:30 AM, Denys Vlasenko
> <vda.linux at googlemail.com> wrote:
> > On Friday 21 May 2010 04:28, John Williams wrote:
> >> Hi,
> >>
> >> I'm running a pure BusyBox v1.14.3 rootfs on a PPC440 environment, and
> >> am seeing some strange behaviour at the initial login prompt.  Console
> >> device is a Xilinx uartlite (mainline driver 2.6.31-stable) on
> >> /dev/ttyUL0
> >>
> >> Here's inittab:
> >>
> >> ~ # cat /etc/inittab
> >> ::sysinit:/etc/rc.sysinit
> >> ::shutdown:/etc/rc.reboot
> >> ::ctrlaltdel:/sbin/reboot
> >> ttyUL0::respawn:/bin/getty -L 115200 ttyUL0 vt100
> >> ::respawn:/bin/syslogd -n
> >> ::respawn:/bin/flatfsd
> >> ::sysinit:/bin/inetd /etc/inetd.conf
> >
> > Try experimenting with adding string "null" as tty
> > for last three lines, anstead of leaving it empty.
> 
> Success!  This resolves the local echo of the username and need to ^D
> the getty/login prompts.  I gave each inittab entry null tty (except
> rc.sysinit) just to be sure.

Please experiment and find the minimum set of nulls you need for this.
This might help to find a bug in e.g. syslogd.

> However, I still see the race between 'cat /etc/motd' with the getty
> login - see below
> 
...
> >>  * If I 'cat /etc/motd' at the end of my rc.sysinit script, the MOTD
> >> output gets truncated (last line incomplete or missing), instead it is
> >> interrupted by the login: prompt.  It's like there's some kind of race
> >> between the init scripts and getty.
> >
> > Yes. Check your /etc/rc.sysinit that it does not start
> > something in background so that this "something" runs even
> > after /etc/rc.sysinit exits (and then init proceeds to start
> > respawn services); or all backgrounded processes are properly
> > isolated. Instead of simple:
> >
> > command args &
> >
> > do something like:
> >
> > setsid command args </dev/null >/dev/null 2>&1 &
> >
> > bacause bare "command args &" retains stdin/out/err of the parent
> > (which is /dev/console == /dev/ttyUL0 in your case)
> > and if it, or one of its children, plays with termio settings
> > of stdin/out/err, it affects it _globally_.
> 
> OK - thanks for the info.
> 
> The last line of /etc/rc.sysinit is
> 
> cat /etc/motd
> 
> The last 30 or so chars of the motd are not displayed - getty races and wins.

I think it's because of serial console being not that fast.
getty sets termios attrs with TCSANOW, not TCSADRAIN.
Thus it stomps on UART before UART flushes output.

> If rc.sysinit has a short sleep after cat /etc/motd (like sleep 0.1)
> it all comes out fine.
> 
> Maybe getty is starting, and resetting the tty before the serial
> driver has drained the buffer?
> 
> Is there a more robust startup sequence that can make sure that
> rc.sysinit completes before getty starts up?

We can use TCSADRAIN in getty.

However, we already seem to be performing flush here,
just a bit differently:

static void termios_init(struct termios *tp, int speed, struct options *op)
{
        speed_t ispeed, ospeed;
        /*
         * Initial termios settings: 8-bit characters, raw-mode, blocking i/o.
         * Special characters are set after we have read the login name; all
         * reads will be done in raw mode anyway. Errors will be dealt with
         * later on.
         */
#ifdef __linux__
        /* flush input and output queues, important for modems! */
        ioctl(0, TCFLSH, TCIOFLUSH); /* tcflush(0, TCIOFLUSH)? - same */
#endif
...

To make sure, check that this #ifdef actually is compiled in.

-- 
vda