Date: Tue, 16 Jan 2001 12:25:06 -0500 From: Brian Reichert <reichert@numachi.com> To: freebsd-hackers@freebsd.org Subject: Re: open PR WRT syslogd vs. serial consoles Message-ID: <20010116122506.A59240@numachi.com> In-Reply-To: <20010105141204.F14544@numachi.com>; from reichert@numachi.com on Fri, Jan 05, 2001 at 02:12:04PM -0500 References: <20010105141204.F14544@numachi.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Jan 05, 2001 at 02:12:04PM -0500, Brian Reichert wrote: > I'm chasing down a syslogd problem on a 3.4-R box, only to discover > that I'm being bit (still!) by a PR I submitted two years ago: > > <http://www.FreeBSD.org/cgi/query-pr.cgi?pr=8865>; > > I'm responsible for a wad of machines hanging off of a terminal server. > > - I wanted syslog messages reported to the console, for revealing > critical errors. > > - Due to cabling and the terminal server itself, using Big Digi > hardware, I need to have getty running off of cuaa0, not ttyd0. > > Apparently, in three versions of FreeBSD, this is _still_ a problem. > > Does anyone have any insight on this? I have a wee bit more insight on this. The gotcha seems to involve getty vs ttyd0 and cuaa0. I want to accomplish at least these things (a bit more fleshed out): - boot messages to the serial port (hence, a serial console) - a login prompt (hence, I need getty running) - syslog logging to /dev/console (as opposed to root's tty) - the general ability to write to the console directly (ie: /bin/echo 'test to console' > /dev/console) - due to serial cabling issues out of my control, it appears that I need getty attached to cuaa0, rather than ttyd0. (The test box below doesn't have this restriction, but I'm trying to spec several boxes in the data center, and there seem to be some variability in the cables that are resolved in using cuaa0.) I have a 3-4.RELEASE box, with a serial console. mdb1# dmesg | grep sio0 sio0 at 0x3f8-0x3ff irq 4 flags 0x10 on isa sio0: type 16550A, console My observations so far: - If getty is not running at all on the serial device, then both syslogd and direct writes to /dev/console just work. - If getty is running on cuaa0, writes to the console by either syslogd or a direct write block. 'ps' shows the process's state as 'I', and it's flags are '86', neither of which reveals much info. :/ (Advice is welcome about getting more info without 'ktrace'...) - If getty is running on ttyd0, then the direct writes work, but syslog doesn't. So - it would seem that out-of-the-box, FreeBSD can't be used adequately in a headless environment, as much as it pains me to state as much. In researching the mailing list archives (well, several lists, but you know what I mean), it would seem people have been running into problems associated with these issues for a couple of years now, over a few versions of FreeBSD. - Is anyone actually able to use FreeBSD in a headless environment with impunity, as per my needs above? If so, specs of hardware/software would be most welcome. - Any advice on kernel/device driver tweaking to resolve the blocking issues would also be appreciated... - What would the ramifications be of running getty on /dev/console? There seem to be a line in /etc/ttys for /dev/console, but I can't fathom why it's there... -- Brian 'you Bastard' Reichert <reichert@numachi.com> 37 Crystal Ave. #303 Daytime number: (603) 434-6842 Derry NH 03038-1713 USA Intel architecture: the left-hand path To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20010116122506.A59240>