RE: using tip on machine that has COMCONSOLE set to serial

From: Terry Lambert [mailto:tlambert2_at_mindspring.com]
> Don Bowman wrote:
> > This may be a dumb question, but I have
> > a situation where machine A and B both have
> > enabled serial console. I'm ssh'ing into A to
> > try and debug a problem on B. I'm trying to
> > use tip, but am getting interference from the
> > fact that A also has a serial console.
> > 
> > If i disable the getty, its a bit better.
> > 
> > Is there a way to make this work reliably, or
> > am I SOL?
> 
> Use or modify a getty to require multiple CR's to activate.  Or
> use one that only activates on a break.
> 
> Best would be to use a getty that respected lock files, needed
> 2 CR's to start after off-to-on DTR/DCD transition (you will be
> using a NULL-modem cable), and your tip/cu/whatever program did
> appropriate locking, and knew how to back off.
> 
> Then you could put the getty's back-to-back and they would not
> chat each other to death, and you could call out of the one
> machine into the other, and your local getty would not eat half
> the characters.
> 
> See also "uugetty" and "mgetty" in ports.

What i ended up doing which worked OK was to changed /etc/ttys
on the machine i wanted to run tip on to comment out the 'ttyd0'
line, and HUP init. I then installed 'minicom' port, and used
it. The machine i was running it on has to be quiescent so no
kernel printfs occur. minicom used /dev/cuaa0.

Bruce Evans suggested using 'db' to poke a '0xc3' into the
kernel printf start to make it return right away, if this
were a bigger problem for me I would give that a try.

--don