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 <[EMAIL PROTECTED]> 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 - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html