(RADIATOR) Radiator going down after Oracle SQL Timeout

[Mariano Absatz]

I'm logging Radiator's stdout/stderr, but the logger rotated and erased it by 
the time I got access to the host (it's a customer's host and when there's 
nothing 'broken' I don't get access too fast). I increased the log size & 
number and the next time it happens, I'll send them.

El 13 Dec 2001 a las 12:13, Hugh Irvine escribió:

> 
> Hello Mariano -
> 
> What you describe below sounds to me like a problem with the DBD-Oracle 
> module. I would suggest that you try to use the "restartWrapper" program that 
> we provide in the distribution ("goodies/restartWrapper") instead of 
> "supervise" (at least for debugging this problem). The restartWrapper program 
> can be set up with a delay before restarting, and it can also be configured 
> to email a designated email address with the exit status and any error 
> messages that were written to stderr. We should then be able to see what is 
> causing Radiator to die.
> 
> regards
> 
> Hugh
> 
> 
> On Thu, 13 Dec 2001 08:14, Mariano Absatz wrote:
> > Hi,
> >
> > I'm having the following problem:
> >
> > I'm using Radiator (2.18.4) and have all of my data on a remote Oracle
> > (8.1.6) server.
> >
> > Both machines are Sun Netra with Solaris 8. Perl version is 5.6.1.
> >
> > There are two instances of Radiator (one for authentication and the other
> > for accounting).
> >
> > The problem is the following. If the Oracle server goes down, the queries
> > time out (that's reasonable). The point is some times (not after every SQL
> > timeout, but after some of them), Radiator goes down. It seems to be that
> > this happens when the query in question is necessary as part of the
> > authentication (e.g. during a username lookup or simultaneous use or port
> > limit check), but not when it is nonessential (as a deletion from the
> > radonline table for the nas/port recently received or an insertion in an
> > AuthLog).
> >
> > On only one ocassion I saw the "Could not connect to any SQL database.
> > Request is ignored. Backing off for 600 second" message, but even that
> > time, Radiator went down.
> >
> > I'm using daemontool's supervise (http://cr.yp.to/daemontools.html) to keep
> > the servers running so the server starts up again almost immediately. I see
> > the messages when it is starting again in the log.
> >
> > The question is, why is Radiator silently shutting down rather than backing
> > off?
> >
> > One of the main problems is that on the almost immediate restart, the first
> > thing Radiator tries to do is to read the client list from the database. If
> > Oracle is still down, it won't read it, it won't retry, and (since there
> > are no hardwired <Client>'s in the config file, it won't accept anything
> > from any NAS.
> >
> > Regretfully, supervise's log is autorotated and autoerased on a size basis
> > and I don't have the output to correlate with Radiator's log.
> >
> > I'm attaching parts of the logs showing the SQL Timeout error immediately
> > followed by Radiator starting up again (via supervise).
> >
> > The "DEBUG: Adding Clients from SQL database" is the first message issued
> > by a NEW Radiator starting.
> >
> > I'm also attaching the whole set of configuration files (the main one is
> > radius-main.cfg) in a zip file.
> 
> -- 
> Radiator: the most portable, flexible and configurable RADIUS server
> anywhere. Available on *NIX, *BSD, Windows 95/98/2000, NT, MacOS X.
> -
> Nets: internetwork inventory and management - graphical, extensible,
> flexible with hardware, software, platform and database independence.


--
Mariano Absatz
El Baby
----------------------------------------------------------
A woman's favorite position is CEO.


===
Archive at http://www.open.com.au/archives/radiator/
Announcements on radiator-announce at open.com.au
To unsubscribe, email 'majordomo at open.com.au' with
'unsubscribe radiator' in the body of the message.