Re: Automatic Reinitialization of connections

Bryan,

Thanks for the quick response.

Here is the conserver output for the behaviour I am experiencing (I will
send a debug file directly to your address). In the following example I
have intentionally created a problem in the custom expect script that
performs the console connection (automated telnet and login into a Sun
RSC card). You notice it automatically retries immediately. The small
delay between each try is the expect script attempting the connection
(intentional problem was failed login into RSC). 

conserver.cf line: 'rschost:|/opt/conserver/bin/rsclogin arg1 arg2::&::'

conserver (17341): conserver.com version 7.2.1 
conserver (17341): Started as `root' by `auser' at Tue May 28 16:06:03
2002 
conserver (17342): lost carrier on rschost (/dev/pts/4)! [Tue May 28
16:06:07 2002] 
conserver (17342): rschost: automatic reinitialization [Tue May 28
16:06:07 2002] 
conserver (17342): lost carrier on rschost (/dev/pts/4)! [Tue May 28
16:06:12 2002] 
conserver (17342): rschost: automatic reinitialization [Tue May 28
16:06:12 2002] 
conserver (17342): lost carrier on rschost (/dev/pts/4)! [Tue May 28
16:06:16 2002] 
conserver (17342): rschost: automatic reinitialization [Tue May 28
16:06:16 2002] 
conserver (17342): lost carrier on rschost (/dev/pts/4)! [Tue May 28
16:06:21 2002] 
conserver (17342): rschost: automatic reinitialization [Tue May 28
16:06:21 2002] 
conserver (17341): Stopped at Tue May 28 16:06:22 2002 

Another example I have experienced is to have a console connection to a
host that does not exist

conserver (17254): conserver.com version 7.2.1 
conserver (17254): Started as `root' by `auser' at Tue May 28 16:03:11
2002 
conserver (17255): lost carrier on blah (/dev/pts/4)! [Tue May 28
16:03:11 2002] 
conserver (17255): blah: automatic reinitialization [Tue May 28 16:03:11
2002] 
conserver (17255): lost carrier on blah (/dev/pts/4)! [Tue May 28
16:03:11 2002] 
conserver (17255): blah: automatic reinitialization [Tue May 28 16:03:11
2002] 
conserver (17255): lost carrier on blah (/dev/pts/4)! [Tue May 28
16:03:12 2002] 
conserver (17255): blah: automatic reinitialization [Tue May 28 16:03:12
2002] 
conserver (17255): lost carrier on blah (/dev/pts/4)! [Tue May 28
16:03:12 2002] 
conserver (17255): blah: automatic reinitialization [Tue May 28 16:03:12
2002] 
conserver (17255): lost carrier on blah (/dev/pts/4)! [Tue May 28
16:03:12 2002] 
conserver (17255): blah: automatic reinitialization [Tue May 28 16:03:12
2002] 
conserver (17255): lost carrier on blah (/dev/pts/4)! [Tue May 28
16:03:12 2002] 
conserver (17255): blah: automatic reinitialization [Tue May 28 16:03:12
2002] 
conserver (17255): lost carrier on blah (/dev/pts/4)! [Tue May 28
16:03:12 2002] 
conserver (17255): blah: automatic reinitialization [Tue May 28 16:03:12
2002] 
conserver (17255): lost carrier on blah (/dev/pts/4)! [Tue May 28
16:03:12 2002] 
conserver (17255): blah: automatic reinitialization [Tue May 28 16:03:12
2002] 
conserver (17255): lost carrier on blah (/dev/pts/4)! [Tue May 28
16:03:12 2002] 
conserver (17255): blah: automatic reinitialization [Tue May 28 16:03:12
2002] 
conserver (17255): lost carrier on blah (/dev/pts/4)! [Tue May 28
16:03:13 2002] 
conserver (17255): blah: automatic reinitialization [Tue May 28 16:03:13
2002] 
conserver (17254): Stopped at Tue May 28 16:03:13 2002 

I hope this helps
Malcolm

Bryan Stansell wrote:
> 
> On Tue, May 28, 2002 at 12:20:07PM +1200, Malcolm Gibbs wrote:
> > Without any arguments to conserver it appears to go into a very tight
> > loop retrying console connections that are not currently available. This
> > can consume a large amount of resource (CPU and disk log files).
> 
> hmmm..."that shouldn't happen".  :-/
> 
> > I did notice a discussion thread about this in Dec 2001 but the code
> > appears to have changed significantly since, potentially making the
> > advice out-of-date (see
> > https://www.conserver.com/pipermail/users/2001-December/msg00003.html).
> 
> yep, that's out of date.
> 
> > My preference would be to have failed console connections stay in a down
> > state to be rectified and manually restarted at a later date.
> >
> > Does conserver support this scenario by default?
> 
> it should, kinda.  actually, it's supposed to retry the connection, and
> if that fails, it will keep the console down.  if you use the -o or -O
> flags, then that changes.  now, if the connection goes up, however
> briefly, and then goes away, you can get a fairly tight loop as it
> appears to bring up the console, then loses it, then brings it up,
> etc...
> 
> > Can somebody advise code changes for conserver 7.2.1 to turn off the
> > automatic reinitialisation?
> 
> well, there are multiple points now.  line 1378 of conserver/group.c
> has 'ReUp(pGe, 1)' - that's where it retries consoles every minute
> (those that went down hard) - you'll want to comment that out.  there's
> also stuff around line 1429 - 'ConsInit(pCEServing, &pGE->rinit, 0);'.
> you'll want to comment that out and the following if, replacing it with
> 'ConsDown(pCEServing, &pGE->rinit);'.  i'm pretty sure that'll cover
> the bases.
> 
> but, more interesting to me is why this is happening.  it really
> shouldn't if those consoles are really down.  would you be willing to
> send me the log output of conserver so i can see how it's looping?  to
> really tell what's going on we may need to run with the debug flag as
> well.  if this isn't a bug (which it may be, but i'm hoping it isn't),
> this may be a configuration issue with the consoles, or even another
> setup situation that the conserver code should be aware of (assumptions
> that it shouldn't be making, for example).
> 
> i hope this helps, and i would love to know why it's in such a tight
> loop...it really shouldn't be.
> 
> Bryan
> _______________________________________________
> users mailing list
> users@conserver.com
> https://www.conserver.com/mailman/listinfo/users

-- 
Malcolm Gibbs
Sun Microsystems (NZ) Ltd
mobile (021) 285 9196