signal handling bugs continue in 7.2.0 on *BSD

I can still reproduce the problem with feeding stdin to the "console"
command causing conserver to crash.  However in 7.2.0 it now only
happens when you have to use 'console -F'.  (maybe that's the only way
it failed in 7.1.3 too -- I can't remember if I only tested with '-F'
then too or not, though I may very well have)

This is with conserver-7.2.0, on NetBSD-1.5W/sparc.

This stdin trick works fine without '-F' though ('very' is a
not-so-important conserver host to which a caller-ID box is attached and
it behaves like a modem with an AT command syntax):

	$ printf "at\r\n" | console -M very callerid
	[Enter `^Ec?' for help]
	$ tail /var/log/consoles/callerid
	[-- woods@very.weird.com attached -- Wed Apr 24 19:17:17 2002]
	[-- woods@very.weird.com detached -- Wed Apr 24 19:17:17 2002]
	at
	[Wed Apr 24 19:17:18 2002]OK
	[Wed Apr 24 19:17:18 2002]

However with another console session attached an attempt to do the above
with 'console -F' causes the following:

conserver (163): conserver(165): signal(13), restarted [Wed Apr 24 19:10:05 2002]

Note that 'console -f' does work though:

	$ printf "at\r\n" | console -f -M very callerid
	[Enter `^Ec?' for help]
	$ tail /var/log/consoles/callerid               
	[-- woods@very.weird.com bumped woods@becoming.weird.com -- Wed Apr 24 19:20:20 2002]
	[-- woods@very.weird.com detached -- Wed Apr 24 19:20:21 2002]
	[-- woods@becoming.weird.com attached -- Wed Apr 24 19:20:21 2002]
	[Wed Apr 24 19:20:21 2002]at
	[Wed Apr 24 19:20:21 2002]OK
	[Wed Apr 24 19:20:21 2002]

With a delay in the right place I don't even have to read the log file
to see the results -- they appear on stdout as expected:

	$ (printf "at\r\n"; sleep 5) | console -f -M very callerid
	[Enter `^Ec?' for help]
	[bumped woods@becoming.weird.com]
	
	at
	OK
	
	$ 

What's interesting is that 'console -F' works fine with the delay:

	$ (printf "at\r\n"; sleep 5) | console -F -M very callerid 
	
	[Enter `^Ec?' for help]
	[bumped woods@becoming.weird.com]
	[replay]
	[Wed Apr 24 19:19:29 2002]at
	[Wed Apr 24 19:19:29 2002]OK
	[Wed Apr 24 19:19:29 2002]
	[-- woods@becoming.weird.com attached -- Wed Apr 24 19:20:08 2002]
	[Wed Apr 24 19:20:10 2002]at 
	[Wed Apr 24 19:20:13 2002]OK
	[-- woods@very.weird.com bumped woods@becoming.weird.com -- Wed Apr 24 19:20:20 2002]
	[-- woods@very.weird.com detached -- Wed Apr 24 19:20:21 2002]
	[-- woods@becoming.weird.com attached -- Wed Apr 24 19:20:21 2002]
	[Wed Apr 24 19:20:21 2002]at
	[Wed Apr 24 19:20:21 2002]OK
	[Wed Apr 24 19:20:21 2002]
	[-- woods@very.weird.com bumped woods@becoming.weird.com -- Wed Apr 24 19:27:30 2002]
	[Wed Apr 24 19:27:30 2002]at
	[Wed Apr 24 19:27:31 2002]OK
	[Wed Apr 24 19:27:31 2002]
	[-- woods@very.weird.com detached -- Wed Apr 24 19:27:35 2002]
	[-- woods@becoming.weird.com attached -- Wed Apr 24 19:27:35 2002]
	[-- woods@very.weird.com bumped woods@becoming.weird.com -- Wed Apr 24 19:28:29 2002]
	at
	OK
	
	$ 

Note also that 'console -F' doesn't work properly at all if no other
session is attached and there's no delay before stdin is closed.  The
log shows the input from the client, but no output in response from the
port -- it's as if the input from the client never makes it out the
port even though it's logged....

Don't ask me why I was trying 'console -F' when I don't really need the
replay action -- probably just out of habit! :-)

At least now I can begin to write Cricket and NUT-UPS support for my UPS
units!  I think for now I'll parse the log file for now instead of
delaying stdin and reading stdin -- that way I can just run a simple
cron job to send the commands to the UPS'....

-- 
								Greg A. Woods

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