Date: Sat, 27 May 2006 18:05:43 -0700 From: Doug Barton <dougb@FreeBSD.org> To: Poul-Henning Kamp <phk@phk.freebsd.dk> Cc: arch@freebsd.org Subject: Re: A sort of plan for consoles in FreeBSD Message-ID: <4478F767.5090403@FreeBSD.org> In-Reply-To: <16029.1148764704@critter.freebsd.dk> References: <16029.1148764704@critter.freebsd.dk>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4478F767.5090403>