I'm trying to use newsyslog on FreeBSD 6.2/freeradius-1.1.6 to rotate my log files an ensure I will never exceed a certain logfile size. My newsyslog.conf file says /var/log/radius/radius.log barry:admin 640 10 10000 * J /var/run/radiusd/radiusd.pid /var/log/radius/*tmp barry:admin 600 10 10000 * JBG /var/log/radius/sqltrace.sql barry:admin 640 10 10000 * J /var/log/radius/radacct/*/* barry:admin 640 10 10000 * JG 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. 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). What could be the problem? Does freeradius actually close and reopen its log files when receiving SIGHUP? I can't find any documentation on other signals... :-( radiusd: FreeRADIUS Version 1.1.6, for host i386-portbld-freebsd6.2, built on May 13 2007 at 22:44:09 radiusd -X output (...) Sending Accounting-Response of id 223 to 165.145.226.12 port 3799 Finished request 4 Going to the next request --- Walking the entire request list --- Cleaning up request 4 ID 223 with timestamp 464cddb9 Nothing to do. Sleeping until we see a request. --- Walking the entire request list --- Nothing to do. Sleeping until we see a request. Reloading configuration files. reread_config: reading radiusd.conf Config: including file: /usr/local/etc/raddb/clients.conf Config: including file: /usr/local/etc/raddb/postgresql.conf main: prefix = "/usr/local" main: localstatedir = "/var" main: logdir = "/var/log/radius" main: libdir = "/usr/local/lib" main: radacctdir = "/var/log/radius/radacct" main: hostname_lookups = no main: snmp = no main: max_request_time = 30 main: cleanup_delay = 5 main: max_requests = 1024 main: delete_blocked_requests = 0 main: port = 62515 main: allow_core_dumps = no main: log_stripped_names = no main: log_file = "/var/log/radius/radius.log" main: log_auth = yes main: log_auth_badpass = yes main: log_auth_goodpass = no main: pidfile = "/var/run/radiusd/radiusd.pid" main: user = "barry" main: group = "barry" main: usercollide = no main: lower_user = "no" main: lower_pass = "no" main: nospace_user = "no" main: nospace_pass = "no" main: checkrad = "/usr/local/sbin/checkrad" main: proxy_requests = no security: max_attributes = 20 security: reject_delay = 2 security: status_server = no main: debug_level = 0 read_config_files: reading dictionary read_config_files: reading naslist read_config_files: reading clients read_config_files: reading realms Fri May 18 00:57:01 2007 : Info: rlm_exec: Wait=yes but no output defined. Did you mean output=none? Fri May 18 00:57:01 2007 : Error: radiusd.conf[262] Auth-Type PAP already configured - skipping Fri May 18 00:57:01 2007 : Info: rlm_sql (auth): Driver rlm_sql_postgresql (module rlm_sql_postgresql) loaded and linked Fri May 18 00:57:01 2007 : Info: rlm_sql (auth): Attempting to connect to radiusd@localhost:/mydb Fri May 18 00:57:01 2007 : Info: rlm_sql (acct): Driver rlm_sql_postgresql (module rlm_sql_postgresql) loaded and linked Fri May 18 00:57:01 2007 : Info: rlm_sql (acct): Attempting to connect to radiusd@localhost:/mydb Fri May 18 00:57:01 2007 : Info: Ready to process requests. Segmentation fault: 11
barry steyn 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.
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 Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog
On 5/18/07, Alan DeKok <aland@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
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@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
Brian A. Seklecki wrote:
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?
As always, patches are welcome. Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog
On 5/18/07, Brian A. Seklecki <lavalamp@spiritual-machines.org> wrote:
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
I've certainly looked at that possibility, the problem is that you cannot separate your logging components nicely. I'd like to separate my radius.log, sqltrace, detail logfiles per nas and all that. I'm afraid that syslog can't do that and you'll run out of log facilities very quickly if you decided to do it manually (e.g. one facility per logfile). I found a workaround (no HUP) so I'm happy. Jack
On Fri, 2007-05-18 at 17:09 +0200, Jack J Allan wrote:
On 5/18/07, Brian A. Seklecki <lavalamp@spiritual-machines.org> wrote: 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
I've certainly looked at that possibility, the problem is that you cannot separate your logging components nicely. I'd like to separate my radius.log, sqltrace, detail logfiles per nas and all that. I'm afraid that syslog can't do that and you'll run out of log facilities very quickly if you decided to do it manually ( e.g. one facility per logfile).
I found a workaround (no HUP) so I'm happy.
Jack I have not checked in quite a while, but at one point a while back, I suggested using configurable dynamic log file names, like the detail files have. I used to use such a beast on a version of Cistron Radius that I customized, but I ran into problems trying to make it work with FR because if I remember correctly, and it is quite possible I do not, there was some kind of problem I ran into where the "Xlate" function did not generate what I expected when it had insufficient data to resolve the log file "name" due to the type of error. Having the configurable logging was low on my list of priorities back then and has not become any more important as of now, but it would still be a nice feature if their was a way to use defaults using "{{variable}:-default}" type entries.
On Fri 18 May 2007, Guy Fraser wrote:
On Fri, 2007-05-18 at 17:09 +0200, Jack J Allan wrote:
On 5/18/07, Brian A. Seklecki <lavalamp@spiritual-machines.org> wrote: 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
I've certainly looked at that possibility, the problem is that you cannot separate your logging components nicely. I'd like to separate my radius.log, sqltrace, detail logfiles per nas and all that. I'm afraid that syslog can't do that and you'll run out of log facilities very quickly if you decided to do it manually ( e.g. one facility per logfile).
I found a workaround (no HUP) so I'm happy.
Jack
I have not checked in quite a while, but at one point a while back, I suggested using configurable dynamic log file names, like the detail files have. I used to use such a beast on a version of Cistron Radius that I customized, but I ran into problems trying to make it work with FR because if I remember correctly, and it is quite possible I do not, there was some kind of problem I ran into where the "Xlate" function did not generate what I expected when it had insufficient data to resolve the log file "name" due to the type of error. Having the configurable logging was low on my list of priorities back then and has not become any more important as of now, but it would still be a nice feature if their was a way to use defaults using "{{variable}:-default}" type entries.
I second this.. But its a low priority.. -- Peter Nixon http://www.peternixon.net/ PGP Key: http://www.peternixon.net/public.asc
Guy Fraser wrote:
I have not checked in quite a while, but at one point a while back, I suggested using configurable dynamic log file names, like the detail files have. I used to use such a beast on a version of Cistron Radius that I customized, but I ran into problems trying to make it work with FR because if I remember correctly, and it is quite possible I do not, there was some kind of problem I ran into
The "radlog" function doesn't take a "REQUEST*". If it did, a configurable log filename would be easy. Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog
participants (6)
-
Alan DeKok -
barry steyn -
Brian A. Seklecki -
Guy Fraser -
Jack J Allan
-
Peter Nixon