On Tue, 24 Sep 2002 10:26:53 -0400
"Alan DeKok" <[EMAIL PROTECTED]> wrote:

> Peter Nixon <[EMAIL PROTECTED]> wrote:
> > I have hit a VERY annoying bug in FreeRadius today which took out both
> > of my accouting servers (the 3rd one is already down, in the process of
> > being rebuilt)
> > The error in question seems to be when a file reaches > 2GB in size,
> > freeradius just quits without logging any error message!
> 
>   It looks to me like it's either a bug with FreeRADIUS treating
> offsets as signed 32-bit integers, OR, your system can't handle files
> larger than 2G.  (Some still exist...)

Will check more tomorrow.. Thanks.

> > The only way to find this problem was to run both servers under
> > debugging mode (as there was no log of the problem) and then try and
> > find WHICH file was so big that freeradius couldn't write to it. (The
> > error message does not state which file)
> 
>   So what was the error message?  FreeRADIUS does NOT contain any
> checks for "file too big", so if you see a message like that, the
> problem is definitely your OS.

That was not the exact error message. I am sorry, I will post the correct
one when I have a spare server built and I can regenerate the problem.
One OS was SuSE 8.0 on ReiserFS (on LVM, on RAID) and the other was RedHat
7.2 on Ext2. (Both are running current recommended kernels from the
vendors.)

I will definately spend more time on this tomorrow. Tonight I am simply
worried about recovering several million call records from syslog :-(
 
> > Surely the inability to write to a debugging file (sqltrace.log) or
> > a detail file should not bring the whole server crashing down!?!
> 
>   What, exactly do you suggest the server do?  I'll bet you haven't
> configured any fail-over for the detail module.  So if it can't write
> to the detail file, the ONLY thing it can do is to panic and die.

OK. I wasn't aware there was such a thing as failover for the detail
module. I will check into this.
 
>   Anything else would result in data being lost, which is probably not
> what you want.

Hm. Well, in my case, data was lost by virtue of the server not being
there, and I would prefer it log some of the records (ie for other NASs)
than none at all.

 
> > Is it possible to have the server rotate the files itself in this
> > instance??
> 
>   Sure.  Grab the latest CVS snapshot from tonight (not last night).
> Edit the name of the detail file to be something like:
> 
>   detailfile = ${radacctdir}/%{Client-IP-Address}/detail-%D:%H

Yes. This is how I am doing it by day. I will not change it to hourly.

>   Which will automatically create a new detail file every hour of
> every day.
> > Now I am off to change my rotation to hourly and begin the painfull
> > task of writing a parser to convert my syslog files into a format that
> > can be inserted into my db. I feel a VERY long night comming on :-(
> 
>   Grab the latest code from CVS, then...

I will do. After I finish writing this parser.
Just out of interest, I posted to the devel mailing list re a spec file for
SuSE with no answer. I now have several pieces of misc code (spec files,
perl parsers, sql schemas, sql.conf) which would probably be useful to
others. Should I post them to devel? Is anyone interested in having them?

-- 

Peter Nixon

Attachment: msg09599/pgp00000.pgp
Description: PGP signature

Reply via email to