We're seeing a very odd occurrence on one of our radius servers. To my knowledge, it has only happened once (this morning), but it's the first time it's happened, and we're not entirely sure where to look to find the cause. We're running on a CentOS 6.6 system, with FR v2.1.12, which is the package that is distributed by CentOS/RH. Each day, the logrotate routing rotates the radius.log (and compresses it), and then restarts FR. This morning, however, the radius log showed that the process restarted, but that it did absolutely nothing for the next two hours and 13 minutes. Fri Mar 13 03:27:01 2015 : Info: HUP - loading modules Fri Mar 13 03:27:01 2015 : Info: Module: Reloaded module "attr_filter.access_reject" Fri Mar 13 03:27:01 2015 : Info: Module: Reloaded module "attr_filter.accounting_response" Fri Mar 13 03:27:01 2015 : Info: Module: Reloaded module "files" Fri Mar 13 03:27:01 2015 : Info: Module: Reloaded module "radutmp" Fri Mar 13 03:27:01 2015 : Info: Module: Reloaded module "suffix" Fri Mar 13 03:27:01 2015 : Info: Module: Reloaded module "mschap" Fri Mar 13 03:27:01 2015 : Info: Module: Reloaded module "pap" Fri Mar 13 03:27:01 2015 : Info: Loaded virtual server <default> Fri Mar 13 03:27:01 2015 : Info: Loaded virtual server inner-tunnel Fri Mar 13 05:40:53 2015 : Info: rlm_sql (sql): Driver rlm_sql_mysql (module rlm_sql_mysql) loaded and linked Fri Mar 13 05:40:53 2015 : Info: rlm_sql (sql): Attempting to connect to radius@xxxxxxxxxxxxxxxxx:3306/radius Fri Mar 13 05:40:53 2015 : Info: rlm_sql (sql): Attempting to connect rlm_sql_mysql #0 Fri Mar 13 05:40:53 2015 : Info: rlm_sql_mysql: Starting connect to MySQL server for #0 Fri Mar 13 05:40:53 2015 : Info: rlm_sql (sql): Connected new DB handle, #0 Fri Mar 13 05:40:53 2015 : Info: rlm_sql (sql): Attempting to connect rlm_sql_mysql #1 Fri Mar 13 05:40:53 2015 : Info: rlm_sql_mysql: Starting connect to MySQL server for #1 Fri Mar 13 05:40:53 2015 : Info: rlm_sql (sql): Connected new DB handle, #1 Fri Mar 13 05:40:53 2015 : Info: rlm_sql (sql): Attempting to connect rlm_sql_mysql #2 Fri Mar 13 05:40:53 2015 : Info: rlm_sql_mysql: Starting connect to MySQL server for #2 ... Following these entries, normal authentication/accounting messages resumed, as they had been doing just prior. Has anyone ever run across this? Any thoughts on how we might track it down? Thanks, Jim
Hi,
We're running on a CentOS 6.6 system, with FR v2.1.12, which is the package that is distributed by CentOS/RH. Each day, the logrotate routing rotates the radius.log (and compresses it), and then restarts FR. This morning, however, the radius log showed that the process restarted, but that it did absolutely nothing for the next two hours and 13 minutes.
dont restart the FR process...just use copytruncate as the method in logrotate - thus meaning that if you are using eg EAP cache, the cache stays... also, looks like you are not restarting the service fully but just HUP'ing - 2.1.12 is very very old and so many things have been fixed since that release. if not using 3.0.7 then at least look at upgrading to 2.2.6 (which is actually config compatible to your version so minor work to change) alan
Thanks, Alan. We'll try out the truncate method as a start, and see about upgrading to a newer version, which will likely mean a new server build, just to ensure our service doesn't go down while we build it. What's curious to me, after further review, is that it took that entire 2+ hours before FR appeared even to attempt connecting to its database. Would the HUP possibly cause that? Jim On 03/13/2015 11:34 AM, A.L.M.Buxey@lboro.ac.uk wrote: > Hi, > >> We're running on a CentOS 6.6 system, with FR v2.1.12, which is the >> package that is distributed by CentOS/RH. Each day, the logrotate >> routing rotates the radius.log (and compresses it), and then restarts >> FR. This morning, however, the radius log showed that the process >> restarted, but that it did absolutely nothing for the next two hours and >> 13 minutes. > dont restart the FR process...just use copytruncate as the method in logrotate > - thus meaning that if you are using eg EAP cache, the cache stays... also, looks > like you are not restarting the service fully but just HUP'ing - 2.1.12 is very very old > and so many things have been fixed since that release. if not using 3.0.7 then > at least look at upgrading to 2.2.6 (which is actually config compatible to your version so > minor work to change) > > alan > - > List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
On 03/13/2015 12:03 PM, J Kephart wrote: > Thanks, Alan. We'll try out the truncate method as a start, and see > about upgrading to a newer version, which will likely mean a new server > build, just to ensure our service doesn't go down while we build it. > > What's curious to me, after further review, is that it took that entire > 2+ hours before FR appeared even to attempt connecting to its database. > Would the HUP possibly cause that? > > Jim > > > On 03/13/2015 11:34 AM, A.L.M.Buxey@lboro.ac.uk wrote: >> Hi, >> >>> We're running on a CentOS 6.6 system, with FR v2.1.12, which is the >>> package that is distributed by CentOS/RH. Each day, the logrotate >>> routing rotates the radius.log (and compresses it), and then restarts >>> FR. This morning, however, the radius log showed that the process >>> restarted, but that it did absolutely nothing for the next two hours and >>> 13 minutes. >> dont restart the FR process...just use copytruncate as the method in logrotate >> - thus meaning that if you are using eg EAP cache, the cache stays... also, looks >> like you are not restarting the service fully but just HUP'ing - 2.1.12 is very very old >> and so many things have been fixed since that release. if not using 3.0.7 then >> at least look at upgrading to 2.2.6 (which is actually config compatible to your version so >> minor work to change) >> >> alan >> - >> List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html > - > List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html Alan, We did the copytruncate, and it's not had a problem since. Keeping our fingers crossed for the moment, until we can upgrade ... Thanks for the info! Jim
participants (2)
-
A.L.M.Buxey＠lboro.ac.uk -
J Kephart