[Radiuscontext-discuss] Radiuscontext not contexting...

[Sean Reifschneider]

On Wed, Aug 27, 2003 at 04:50:56PM -0700, Jon wrote:
>I'm running RadiusContext-1.88. It runs logs on USR Hiper equipment, an
>Ascend MAX and a PortMaster. When it runs daily it creates the huge data
>file and then starts the second part where it runs the reports. Somewhere
>in there it just stops. I have no idea why, obviously.

By "just stops", I presume you mean that it terminates instead of
meaning that it hangs.  I presume you have some set of scripts that run
radiusContext?  I'd suspect some problems in those, you might want to
try running the reports manually.

If radiusContext aborts for any reason, it will display a traceback
showing exactly where it failed and how it failed.  If you are getting
one of those, I need the full text of it.  If you aren't, it's probably
not a problem in radiusContext.

There is one case where there have been problems in the running of
radiusContext that have had similar results.  In some versions of
Python, there have been problems in one of the database modules that's
used.  There is code in radiusContext to try to override that selection
process and force the use of the good one if it's available.

There are two cases where that selection process will fail and fall back
to the other code.  One is where you have an old SessionData file which
was created with an older version of the code (selecting the other
database).  If you remove the SessionData file and run the reports from
the source detail files using the current radiusContext, that should
clear it up.

The other may be that you do not have the "good" module available.  If
you run "python -c 'import gdbm'" and it doesn't return an error, you
have the good database module.  If it reports an ImportError, you do
not.

This should be all fine on any fairly recent Red Hat Linux or similar
system.  By that I mean something within the last 2 to 3 years.  Other
platforms may or may not have this issue.

>Interesting note. It also runs logs for another set of customers we have
>logging setup on too and their logs run just fine. The difference between
>the two being the first group (broken group) runs logs from 3 different
>types of hardware and the second group is all USR Hiper equipment.

This may simply be a volume-related issue.  If it fails due to parsing
of the detail file, you will definitely get a traceback telling what
exactly the problem was.

Sean
-- 
 There is no force so powerful as an idea whose time has come.
                 -- Everett Dirkson
Sean Reifschneider, Member of Technical Staff <jafo at tummy.com>
tummy.com, ltd. - Linux Consulting since 1995.  Qmail, Python, SysAdmin