Log Rotation

[Brian A. Seklecki]

Another solution would be to perform logging via syslog(3), which
absolves radiusd from trapping and handling signals and file handlers.
Syslog-ng already does this very well -- why duplicate all of that code?
~BAS


On Fri, 2007-05-18 at 14:57 +0200, Jack J Allan wrote:
> On 5/18/07, Alan DeKok <aland at deployingradius.com> wrote:
>         Jack J Allen wrote:
>         > Now in my particular case when newsyslog runs from cron it
>         finds that
>         > radius.log, sqltrace.sql and one of the radacct/*/* files
>         have exceeded
>         > their filesize, so it renames them (*.log.n), touches a new
>         file, in the 
>         > case of radius.log sends a SIGHUP to radiusd and then
>         proceeds to bzip
>         > the renamed logfiles. As you would expect.
>         
>           Don't HUP the server when you rename the log file.  It's not
>         necessary.
> 
> I see, it works perfectly without SIGHUP'ing radiusd. Thanks Alan,
> you're the man. 
> 
> 
>         > The problem is that when radiusd is running normally it
>         starts to chew
>         > up 98% CPU from this point onwards and completely stops
>         responding to
>         > accounting packets. I have to killall -9 radiusd, it won't
>         even respond 
>         > to my SIGTERM. Running in debug mode unfortunately just
>         causes radiusd
>         > to segfault a few seconds after the log rotation (see output
>         below).
>         
>           1.1.x doesn't handle HUP very well.  We hope to fix this in
>         2.0.0
> 
> Alright, it would be awesome if there was a warning somewhere about
> this bug though...
> 
> Jack
> - 
> List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html