[Date Prev] [Date Index] [Date Next] [Thread Prev] [Thread Index] [Thread Next]

Re: Odd ctrl-s problem.

Greg A. Woods woods@weird.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 with.
(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 11:47:54

Resolve Service: Telnet DTR wait: Disabled
Idle Timeout: 0 Typeahead Size: 2048
SLIP Address: SLIP Mask:
Remote SLIP Addr: Default Session Mode: Interactive
TCP Window Size: 256 Prompt: Xyplex
DCD Timeout: 2000 Dialback Timeout: 20
Stop Bits: 1 Script Login: Disabled
TCP Keepalive Timer: 0 Username Filtering: None
Nested Menu: Disabled Nested Menu Top Level: 0
Command Size: 80 Clear Security Entries: Disabled
Rlogin Transparent Mode: Disabled Login Duration: 0
Xon Send Timer: 0 TCP Outbound Address:
Slip Autosend: Disabled Radius Accounting: Disabled

Username Prompt:          Enter username>
Password Prompt:     Enter user password>

As for possible workarounds, does anyone see an issue with sending a ^s
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