[PATCH] getty: Wait until all output written to stdout has beentransmitted

Denys Vlasenko vda.linux at googlemail.com
Mon Jan 24 23:00:14 UTC 2011

On Monday 24 January 2011 22:38, Harald Becker wrote:
> - if at start of getty:


> why is it required? as the tty should have been 
> closed and reopened before, the queues should already be empty.
> So which 
> output get lost, exactly please.

I don't know what output gets truncated. I assume it's kernel
console output.

> What is that flush/drain for ... except
> that very old bug, that changing line setup fails on none empty buffers?

Unfortunately, whoever added that flush forgot to add a detailed comment:

commit 1fca558799350fb6caff97f55aa6d1237b08fccb
Author: Robert Griebl <griebl at gmx.de>
Date:   Tue Jun 4 20:45:46 2002 +0000

    Bigger patch for (partial) tinylogin integration
    - Made a new dir loginutils
    - Moved all applets from pwd_grp to loginutils
    - Added new applets su.c login.c to loginutils
    - Made a new dir libpwdgrp
    - Moved everything from pwd_grp/libpwd_grp there
    - Added shadow.c to libpwdgrp
    - Removed dir pwd_grp
    - Added usage strings for login and su to usage.h
    - Changed main Makefile to reflect the dir rearrangements
    [Parts of this patch may overlap with my other two patches]


+       /*
+        * Initial termio 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
+        * lateron.
+        */
+#ifdef __linux__
+       /* flush input and output queues, important for modems! */
+       (void) ioctl(0, TCFLSH, TCIOFLUSH);

When I see that comment, I think:
"Thanks for informing us that it is important.
It would be awesome if we would also be informed
WHY it is important..."

> ... if at getty startup, a short delay of a second or so, wouldn't be
> that bad, as it is the tty process startup.

That's how I see it too.

> That would even be a good 
> idea, as old init processes sometimes delayed spawning of new (getty)
> processes for several seconds (resulting in tty close - delay - open)

> ... which isn't done by busybox init (as far as I noted some time ago)

I believe it _is_ done:

        /* Now run the looping stuff for the rest of forever.
        while (1) {
                int maybe_WNOHANG;

                maybe_WNOHANG = check_delayed_sigs();

                /* (Re)run the respawn/askfirst stuff */
                run_actions(RESPAWN | ASKFIRST);
                maybe_WNOHANG |= check_delayed_sigs();

                /* Don't consume all CPU time - sleep a bit */
===========>    sleep(1);
                maybe_WNOHANG |= check_delayed_sigs();

                /* Wait for any child process(es) to exit.
                 * If check_delayed_sigs above reported that a signal
                 * was caught, wait will be nonblocking. This ensures
                 * that if SIGHUP has reloaded inittab, respawn and askfirst
                 * actions will not be delayed until next child death.
                if (maybe_WNOHANG)
                        maybe_WNOHANG = WNOHANG;
                while (1) {
                        pid_t wpid;
                        struct init_action *a;

                        /* If signals happen _in_ the wait, they interrupt it,
                         * bb_signals_recursive_norestart set them up that way
                        wpid = waitpid(-1, NULL, maybe_WNOHANG);
                        if (wpid <= 0)

                        a = mark_terminated(wpid);
                        if (a) {
                                message(L_LOG, "process '%s' (pid %d) exited. "
                                                "Scheduling for restart.",
                                                a->command, wpid);
                        /* See if anyone else is waiting to be reaped */
                        maybe_WNOHANG = WNOHANG;
        } /* while (1) */


More information about the busybox mailing list