Re: Odd ctrl-s problem.
Greg A. Woods email@example.com
Wed, 6 Feb 2008 08:02:13 -0800 (PST)
On 6-Feb-08, at 6:00 AM, Peter Saunders wrote:
Recently, we restarted conserver, (Killed the parent, waited for the
children to exit) - and then started conserver again.
Somewhere between shutting conserver down, or starting it up again, a
significant number of our machines had "ctrl s" sent to the console,
blocking all future /dev/console output. This in turn then caused some
apps that were writing log messages to the console to then block, and
to stop working.
The only common thing we have noticed so far is that the only machines
that seem to have suffered, are the ones we make an ssh connection
(We use exec "ssh -c 3des user:port@hostname", followed by an initcmd
which echo's the password to the console).
Has anyone seen of this issue before? Obviously, I have no idea if it
was conserver, ssh, or the terminal server that caused this - but it
happened at the time conserver was restarted.
The XOFF issue is an oldie for sure. Back when I had Decwriter-III's
on serial consoles I had the habit of always hitting <CTRL-Q> every
morning just in case they had been overflowed and stopped overnight.
The worst is when the kernel obeys XON/XOFF and then it gets hung up
entirely stopping the whole system. This was the case on SunOS, at
least up to 5.9.
It's 99.999% certain that it was the terminal server that caused it,
since it may have been configured to try to pause the output from the
attached device once its input buffer filled, and if its flow control
method is set to XON/XOFF then it would use ^s to pause the output
just as you've observed.
On those old Xyplex MaxServers (which is what I'm running at home
now), and perhaps on the DECservers too since they seem to run code
derived from the same origin, there are several ways of dealing with
device output when there's no connection open to send it down. One
is to increase the typeahead size to a ridiculous amount (assuming
you have enough RAM installed in the maxserver). That's what I've done:
Xyplex>> show port 2 alt ch
Port 2: (Remote) 07 Feb 2008
Resolve Service: Telnet DTR wait:
Idle Timeout: 0 Typeahead
SLIP Address: 0.0.0.0 SLIP Mask:
Remote SLIP Addr: 0.0.0.0 Default Session Mode:
TCP Window Size: 256 Prompt:
DCD Timeout: 2000 Dialback
Stop Bits: 1 Script Login:
TCP Keepalive Timer: 0 Username
Nested Menu: Disabled Nested Menu Top
Command Size: 80 Clear Security Entries:
Rlogin Transparent Mode: Disabled Login
Xon Send Timer: 0 TCP Outbound Address:
Slip Autosend: Disabled Radius Accounting:
Username Prompt: Enter username>
Password Prompt: Enter user password>
As for possible workarounds, does anyone see an issue with sending
with in the "idlestring" ?
That's a better idea than anything else I had thought of so far! :-)
(All I had thought of was sending a ^s with "chat" through initcmd,
but of course that only fixes the problem on startup, not if it
occurs regularly during normal use.)
Greg A. Woods