On 5/18/07, <b class="gmail_sendername">Alan DeKok</b> <<a href="mailto:aland@deployingradius.com">aland@deployingradius.com</a>> wrote:<div><span class="gmail_quote"></span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Jack J Allen wrote:<br>> Now in my particular case when newsyslog runs from cron it finds that<br>> radius.log, sqltrace.sql and one of the radacct/*/* files have exceeded<br>> their filesize, so it renames them (*.log.n), touches a new file, in the
<br>> case of radius.log sends a SIGHUP to radiusd and then proceeds to bzip<br>> the renamed logfiles. As you would expect.<br><br>  Don't HUP the server when you rename the log file.  It's not necessary.</blockquote>
<div><br>I see, it works perfectly without SIGHUP'ing radiusd. Thanks Alan, you're the man. <br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
> The problem is that when radiusd is running normally it starts to chew<br>> up 98% CPU from this point onwards and completely stops responding to<br>> accounting packets. I have to killall -9 radiusd, it won't even respond
<br>> to my SIGTERM. Running in debug mode unfortunately just causes radiusd<br>> to segfault a few seconds after the log rotation (see output below).<br><br>  1.1.x doesn't handle HUP very well.  We hope to fix this in 
2.0.0</blockquote><div><br>Alright, it would be awesome if there was a warning somewhere about this bug though...</div></div><br>Jack<br>