Re: Asynchronous Console Messages?

[Bill Hacker <wbh@xxxxxxxxxxxxx>]

Ben Cadieux wrote:

> Hi everyone,
>
> 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!
>
> Best Regards,
> Ben Cadieux

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 
time-out.

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.

HTH,

Bill Hacker