[ On Wednesday, October 18, 2000 at 13:49:33 (-0700), Greywolf wrote: ]
> Subject: Re: why must exiting processes wait forever for events that never  occur?!?!?!
>
> You must be kidding.  LOG_CONS is there for a reason -- in case syslogd
> isn't running and output has to go SOMEwhere.

No, I'm most definitely not kidding.  In fact I've alread made the
change in my lib/libc/gen/syslog.c -- I just haven't rebuilt the world
yet.  The comment in the code about not worrying if the console blocks
incensed me into wiping out the whole mess completely.

It's either that or flow control on /dev/console has to go away
permanently, and I'd rather have flow control, thank you very much.

No if's and's or but's.

If syslog(3) can't send packets to the log host, or can't write to disk,
then the system's hosed anyway (and maybe it should just panic!  :-)

/dev/console is not somewhere where a process can expect to write
anything unhindered, even if it has appropriate privileges, especially
in multi-user mode.  Flow control, or lack of DCD on a non-local line,
will stop it in its tracks.

The day that I hook a printing console back up to a system and rely on
it for permanent log recording is the only day I'll reneg on this!  :-)

Now if openlog(3) & syslog(3) had some way to do non-blocking opens and
writes to /dev/console then things might be a bit different, but I don't
see an easy way to do that.

However all is not lost.  If I still really want some log messages to
appear on /dev/console I can fix syslogd itself so that it does timeouts
on writes to tty devices and then simply configure whatever messages I
want to be written on /dev/console!  (BTW it's already annoying when
you've got syslogd writing duplicate copies of messages that were also
written by a process that set LOG_CONS.)

The next step is to think long and hard about whether or not the kernel
should block on flow control (or lack of DCD, etc.) when writing its own
messages to /dev/console.  My initial impression is that it shouldn't
ever block -- or at least it should timeout soon enough that other
things don't get all bound up....

-- 
							Greg A. Woods

+1 416 218-0098      VE3TCP      <gwoods@acm.org>      <robohack!woods>
Planix, Inc. <woods@planix.com>; Secrets of the Weird <woods@weird.com>