DragonFly users List (threaded) for 2006-07
Re: Asynchronous Console Messages?
Ben Cadieux wrote:
I've always been a little curious about the way the typical unix
console works. Why is it that applications must wait for text to be
displayed on the console before continuing operation? Shouldn't these
messages merely enter into a queue to be displayed whenever the system
can get to them instead of slowing things down to the maximum speed
they can be output?
Perhaps I'm mistaken about this issue :) -- and I'm certain that if
I'm not there's a reason for it working the way it does. I wouldn't
mind knowing the reason, though!
Historically, the Unix 'console' was most often a DEC Writer, ASR-3X TTY, or
'glass teletype' (ADM-3, SOROQ IQ-120, Televideo 9XX, scads of others) 'dumb'
serial terminal - and these, or modern equivalents, are still supported.
In our case, we use a few carefully preserved HP-200LX - easy to carry on
interncontintal flights, pass though customs in paranoid countries, and usable
as 130-column VT-XX terminals - with special eyeglasses..
Awaiting a hardware or software handshake (RTS/CTS, ACK/NACK, etc) OTOH, is NOT
ordinarily required, and a default VGA or other 'virtual' consle doesn't
necessarily even have the concept (where you can adjust it, anyway).
For the most part, the initiation activities reported to the 'console' are, in
fact, already being 'buffered' or otherwise free-running with respect to the
underlying progress of the activity being reported. Ordinarily, these are
neither constrained by the speed of the I/O device, nor stalled awaiting
handshake or response - though such may be provided for, and can be useful in
certain types of troubleshooting.
The 'delays' are far more often those required by dependencies and sub, and
sub-sub dependencies - most, but not all, of which are also reported. IOW - they
won't change, regardless of the bahaviour of the console, or if it is beong
pipeld to, for example, /var/log/all or /var/log/console.log instead of/as well
as a console I/O animal.
A few examples:
- There are a great many things that must complete before a Unix system is able
to leave the 'single user' mode it uses for booting and enter 'multiuser'.
Mounting (or not) whatever is in ~/etc/fstab among the most obvious.
- *many* of the other 'basics', such as bringing up a NIC, testing that there is
a cable and a working TCP/IP connection, finding the gateway and DNS servers,
etc. - must run to sucessful full/partial completion, ELSE time-out before other
services will attempt to start. SSHD, for example, ordinarily implies
'multiuser' mode, AND must have a means of communication if it is to be of any use.
- *most* applications require that their storage be available, so fsck'ing a
large HDD can delay most anything that either lives on a given resource, or
calls other applications/libraries that do so. We start massive RAID arrays
separately from ~/etc/fstab in ~/etc/rc.d scripts, so as to get a server into an
ssh-capable state more rapidly after a reboot - even if this means soem of its
public-facing services are NOT yet available.
- So too with applications that relay on other applications as prerequisites.
A couple of easy ways to satisfy your curiosity on these include:
- entering a non-available mount into ~/etc/fstab
(thereby stalling in single-user mode, incapable of running ssh, so do this on
a box you can 'reach' physically, not a remote one!)
- disconnecting the CAT5 ethernet cable during bootup, and connecting it much
later. Some services will find it 'late' and initialize, others will not.
- specifying an unreachable network time server, thereby creating a failrly long
In some cases, you can enter a <Ctrl-C> when the relevant message appears and
proceed more quickly - the daemon may or may not initialize later, and you may
or may not proceed sucessfully to a multi-user runlevel.
Note that the <Ctrl-C> is not removing a console delay. It is aborting the
attempt to start that particular process.
Most of this behaviour is configurable in one or more places, preferably with
overrides in boot, loader, or - of course - rc.conf and the content and
sequencing of ~/etc/rc.d scripts.