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...)
> 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.
> 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.
Anything else would result in data being lost, which is probably not
what you want.
> 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
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...
Alan DeKok.
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
