[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:
yes
> 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);
+#endif
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)
break;
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) */
--
vda
More information about the busybox
mailing list