DragonFly BSD
DragonFly users List (threaded) for 2006-07
[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]

Re: Asynchronous Console Messages?

From: Bill Hacker <wbh@xxxxxxxxxxxxx>
Date: Sun, 30 Jul 2006 10:02:01 +0800

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.


Bill Hacker

[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]