A sort of plan for consoles in FreeBSD

[Doug Barton]

Poul-Henning Kamp wrote:

> Today we expect all relevant logging to happen to logfiles, either
> directly (like for instance apache provides for) or via syslogd(8),
> which adds the ability to send the logs to a remote machine in
> real-time.
> 
> Spitting things out on /dev/console today will more likely than
> not, print stuff on a syscons or serial port which nobody looks at.
> For that reason, we added a hack to the kernel to make all stuff
> that went to /dev/console be sent to syslogd(8).

I really like that hack, and enable logging of console.* on all my systems.
Your point about syslogd being able to log remotely is also a good one.
However the good old fashioned /dev/console is not as anachronistic as you
might think. Where I used to work we had a very handy serial console program
that "listened" to the serial console output and logged it locally. That
way, if a machine crashed, died, or otherwise went unreachable you could log
into the serial console, quickly check the most recent console output, then
try to fix the problem. Whatever output might have gone to a remote syslog
is also useful, but only if the problems were not so fundamental as to have
prevented the remote logging in the first place.

> I would like to redefine the semantics of "/dev/console" as follows:
> 
> 	if any console-consumers like xconsole(8) are active
> 		send output to all console-consumers.
> 	else if a controlling terminal is available
> 		send output to controlling terminal (that is /dev/tty)
> 	else
> 		send output to syslogd, as if generated by printf(9).
> 		(but do not actually output to low-level console)

At first glance I don't see anything wrong with that logic. My one request
is that you add a branch that says, "if legacy behavior is requested by
<some configuration method>, add it to the mix."

hth,

Doug

-- 

    This .signature sanitized for your protection