2017-10-23 20:29 UTC

View Issue Details Jump to Notes ]
IDProjectCategoryView StatusLast Update
0006689CentOS-6freeradiuspublic2014-05-19 00:45
Reportersmytht 
PrioritylowSeverityminorReproducibilityalways
StatusnewResolutionopen 
PlatformX86OSCentos6.xOS VersionCentos 6.0-6.4
Product Version6.4 
Target VersionFixed in Version 
Summary0006689: Freeradius stops on the first of the month each month and doesnt recover
DescriptionEvery Month on the first of the month, freeradius stops and does not recover,
this results in users not being able to utlise free radius until an administrator starts the service again.

on checking /var/log/radiusd/radius.log
one will see in the last entries of the file

Sun Sep 1 03:29:02 2013 : Info: Received HUP signal.
Sun Sep 1 03:29:02 2013 : Info: HUP - Re-reading configuration files

The HUP signal is caused by log rotate configuration stopping the service to rollover the logs.
Steps To Reproduceinstall freeradius...
use it in production ...
wait till the first day of the next month.
free radius will stop in the early hours of the first day of the month.
Additional Informationto fix this issue one should ,
edit line 39 of /etc/logrotate.d/radiusd
change the line from

               /sbin/service radiusd reload
to the following
               /sbin/service radiusd restart
-----------------------------------------------------------
the reload argument seems to not work with radiusd in radius
TagsNo tags attached.
Attached Files

-Relationships
+Relationships

-Notes

~0018740

tigalch (manager)

Does running 'service radiusd reload' by hand work? i.e. is the daemon running afterwards?
The init script for radiusd does mention - depending on the used modules - a reload may not be sufficient, and to use restart instead. So might be due to some specific setup?

~0018741

smytht (reporter)

Hi Tigalch
Running the service radiusd reload didnt work for me if I recall correctly but when i Ran service radiusd restart it did work.
perhaps the etc/init.d/radiusd script needs to be looked at ... ( I think my fix is more of a Hack but it is effective... I think because the service is stopped for log rotate the service should be re-started after the rotation of the logs... reload (AFAIK) only reloads the configuration for a service (if it is running ) perhaps im wrong...
I hope this helps.

Tom Smyth

~0018742

tigalch (manager)

Have you taken a look at the init.d script for radiusd - section reload (or restart)? Maybe this applies to your setup?

~0019758

shota.suzuki (reporter)

Hi Tom

The same problem occurs in January in my environment, I have rewritten as follows.

/etc/logrotate.d/radiusd
/sbin/service radiusd reload?-> /sbin/service radiusd restart


After changing the settings, I've been working for four months without any problem.
However, today, the problem has been recurrence.
Do you have a solution?

-----------------------------log------------------------------------------------------
sudo zmore /var/log/radius/radius.log-20140515.gz | grep "May 15 04:13"

Thu May 15 04:13:02 2014 : Info: Signalled to terminate
Thu May 15 04:13:02 2014 : Info: Exiting normally.


sudo less /var/log/radius/radius.log

Thu May 15 04:13:03 2014 : Info: Loaded virtual server <default>
Thu May 15 04:13:03 2014 : Info: Loaded virtual server inner-tunnel
Thu May 15 04:13:03 2014 : Info: ... adding new socket proxy address * port 58593
Thu May 15 04:13:03 2014 : Info: Ready to process requests.
Thu May 15 04:31:26 2014 : Info: Loaded virtual server <default>
Thu May 15 04:31:26 2014 : Info: Loaded virtual server inner-tunnel
Thu May 15 04:31:26 2014 : Info: ... adding new socket proxy address * port 58783
Thu May 15 04:31:26 2014 : Info: Ready to process requests.
----------------------------------------------------------------------------------------

4:31 AM I ran "service radiusd start"

~0019765

shota.suzuki (reporter)

(0019758)
additional information is here,

/var/log/messages
May 15 04:13:03 nwtftp1 [kern.info] radiusd[29873] general protection ip:7f7531d93a22 sp:7f7529ff5f40 error:0 in libc-2.12.so[7f7531d1e000+189000]
+Notes

-Issue History
Date Modified Username Field Change
2013-10-01 18:48 smytht New Issue
2013-12-29 20:04 tigalch Note Added: 0018740
2013-12-29 20:13 smytht Note Added: 0018741
2013-12-30 08:58 tigalch Note Added: 0018742
2014-05-15 02:48 shota.suzuki Note Added: 0019758
2014-05-19 00:45 shota.suzuki Note Added: 0019765
+Issue History