Re: more on reinitialization

yowsers.  well, i have a suggestion and a question.  first the
question.  are there any indications of why the ssh process exits with
a 255 in the log files (like /var/log/port38.log)?  that might help
explain exactly why things are going wild.

my suggestion is this.  there is a usleep(100000) in
conserver/consent.c:757.  you could try copying that to line 873 as
well (just before the VirtDev() call).  my theory (which perhaps the
logfile could confirm) is that the lantronix can't handle many socket
connections (ssh or not) at once.  the code should probably have the
delay anyway, as most program being executed are going to create socket
connections.  the usleep() was in there originally to handle older
cisco equipment that couldn't take almost-simultaneous socket
connections (an ultra2 overpowered it) - and i'm sure other equipment
have similar issues - probably even semi-recent equipment.

anyway, that's my theory and a possible work-around.  if 1/10 of a
second isn't enough, crank it up a little.  let me know if i was at all
on track and if the usleep() helps, ok?

Bryan

On Mon, Dec 09, 2002 at 08:05:48PM -0500, Brown, Ed wrote:
> I am currently testing conserver on a SUN E220 with a Lantronix scs4805
> using openssh v3. If I start up 4 connections at a time, all 48 sessions
> connect without a problem, resulting in 14 conserver processes. However,
> when I attempt to bring up all 48 at once, the system is hammered for
> four-plus minutes while conserver reinitializes the connections, generating
> 13,000 plus messages into the conserver log file such as these:
> 
> conserver (4609): port38: exit(255) [Mon Dec  9 17:48:54 2002]
> conserver (4609): port38: automatic reinitialization [Mon Dec  9 17:48:54
> 2002]
> conserver (4540): port2: exit(255) [Mon Dec  9 17:48:54 2002]
> conserver (4540): port2: automatic reinitialization [Mon Dec  9 17:48:54
> 2002]
...
> After four minutes, conserver calms down and all 48 connections are valid.
> But obviously I'd like to bring all 48 up quietly and efficiently. So I'd
> certainly appreciate help in resolving this. Here are some typical  .cf
> entries