buffered_sql problem

[Ricardo Larrañaga]

Hello Guys:
Just as a refresh, i am working on this problem on i system where i use
buffered_sql. In this system, at times, the server stops processing the
buffered sql file (the file starts growing in length), and wont add more
accounting records until i restart the server. When i do that, the server
process every accounting record that was not processed so far, and
continues working normally until the next time this happens.

I was trying to follow Alan's recommendation on running the server in Debug
mode to catch when the issue happens. I did this by running the server with
radiusd -Xx > radiusdebug.log &

And started collecting detailed logs.
The the issue i ran into then is that the problem does not happen anymore.
I have been running the server in debug mode for weeks now, and i haven't
been able to catch one incident (Before, the incidents could be as often as
twice a week).


When running the radius server in debug mode, the server works in single
thread mode, correct? I wonder if the issue i am experiencing happens only
when the server runs in multi thread mode?

Anyway, i wanted to ask you if you have any recommendation on how to run
the server in multi thread mode and still get the full detailed debug
output. I was thinking about using raddebug with a time of 0 to capture in
a continous way, but i dont know if there is an extra flag to be able to
get the extra detail in the debug (-Xx) ?

Thaks a lot for your help.
Regards


On Fri, Aug 14, 2015 at 5:07 PM, Alan DeKok <aland at deployingradius.com>
wrote:

> On Aug 14, 2015, at 9:47 PM, Ricardo Larrañaga <
> ricardo.larranaga at gmail.com> wrote:
> > To answer your questions, the detail file is full of different packets
> (New
> > packets).
>
>   OK.
>
> > I did a search for Packet-Transmit-Counter > 16 both in the debug output
> > and in the detail file, but i don't see the attribute anywhere, which
> makes
> > me think that the packets are not being re transmitted.
>
>   The attribute won't show up in the debug output.  But if you read the
> debug output, you should see that the same packet is being retransmitted.
> And you should see what's going wrong, and why it's being retransmitted.
>
> > I am trying to get a little bit more information about the issue, but it
> is
> > difficult.
> > I wanted to use raddebug when the issue is happening, but it looks like
> > radddebug is not showing inserts into the accounting database.
> > If i restart the server to use radiusd -X the server starts processing
> the
> > file, and the problem goes away.
> >
> > Any recommendation on how to get more information would be great.
>
>   Run it in debugging mode and get the FULL output.  Disk space is cheap.
> And certainly cheaper than spending days trying to fix the problem, and
> getting nowhere.
>
>   Alan DeKok.
>
>
> -
> List info/subscribe/unsubscribe? See
> http://www.freeradius.org/list/users.html
>