Re: Odd ctrl-s problem.

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:             0.0.0.0     SLIP Mask:             
255.255.255.255
Remote SLIP Addr:         0.0.0.0     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:          
0.0.0.0
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
						<woods@weird.com>