Bug #11013
closed
FreeRADIUS does not start after a package reload or a router bootup/reboot
0%
Description
The FreeRADIUS package is the only package that does not startup after the router reboots or a package reload is done for any reason. After trying several suggested solutions from the Netgate user forums, only the following solution actually resolved the issue:
[[https://forum.netgate.com/topic/78615/freeradius-2-doesn-t-start-after-upgrade-to-pfs-2-2/43]]
The solution involves editing radiusd.sh and changing the rc_stop() function from this:
rc_stop() {
/usr/local/etc/rc.d/radiusd onestop
}
To the following block of code which checks if a service start is already in progress before trying to stop it:
rc_stop() {
if [ ! -f "$LOCKFILE" -a -f "$PIDFILE" ]; then
/usr/local/etc/rc.d/radiusd onestop
fi
}
Can the developers please make this modification as is detailed above?
Updated by Jim Pingle about 4 years ago
- Subject changed from FreeRADIUS does NOT start after a package reload or a router bootup/reboot to FreeRADIUS does not start after a package reload or a router bootup/reboot
- Target version deleted (
2.5.0) - Affected Architecture deleted (
SG-3100)
Updated by Kris Phillips about 4 years ago
- Status changed from New to Feedback
Michael Klein wrote:
The FreeRADIUS package is the only package that does not startup after the router reboots or a package reload is done for any reason. After trying several suggested solutions from the Netgate user forums, only the following solution actually resolved the issue:
[[https://forum.netgate.com/topic/78615/freeradius-2-doesn-t-start-after-upgrade-to-pfs-2-2/43]]
The solution involves editing radiusd.sh and changing the rc_stop() function from this:
[...]
To the following block of code which checks if a service start is already in progress before trying to stop it:
[...]
Can the developers please make this modification as is detailed above?
Attempted to recreate issue. Unable to reproduce.
Steps completed:
1. Fresh install of pfSense
2. Install FreeRADIUS package
3. Ensure service has started
4. Reboot firewall several times
On each reboot, the service started normally and reported no issues starting up. This does not appear to be a bug with the package, unless a step to reproduce in the original bug report is missing.
Updated by Kris Phillips about 4 years ago
- Status changed from Feedback to Rejected
Updated by Michael Klein about 4 years ago
Sorry to hear you couldn't recreate this issue which affects both of our Netgate SG-3100 appliances. The insertion of the conditional statement in the code is just an extra check that would not hurt anything and can only help those experiencing this issue due to a race condition that occurs when run on certain hardware. Therefore, it doesn't affect all users in all environments, but it consistently occurs on our SG-3100's. It obviously affects other users as well as is seen in the forums. I really don't see the harm in adding this extra check. This bug has been present for at least the last 5 years and still hasn't been resolved. Please reconsider making this simple modification which would finally resolve this issue. Thank you.
Updated by Renato Botelho about 4 years ago
- Status changed from Rejected to New
- Assignee set to Renato Botelho
- Target version set to 2.5.0
I'll take this one
Updated by Renato Botelho about 4 years ago
- Status changed from New to Feedback
- Target version deleted (
2.5.0)
This should be fixed in 0.15.7_20
Updated by Renato Botelho about 4 years ago
- Affected Version changed from 2.4.5-p1 to All
Updated by Michael Klein about 4 years ago
Renato, thank you for all your help. I look forward to the new version and will provide feedback. I'm not sure why Jim deleted the specified architecture in my original post.
Updated by Michael Klein about 4 years ago
Hi Renato, I tested the fix on both SG-3100's and it works very well. I'm glad that this issue has finally been resolved!
By the way, I'm sure you know that there is a $LOCKFILE variable defined in freeradius.inc, so there is no need to hardcode it and it would simply look like this:
rc_stop() {
if [ ! -f "$LOCKFILE" ]; then
/usr/local/etc/rc.d/radiusd onestop
fi
}
Anyway, thank you so much for all your help! You can go ahead and close this ticket.
Updated by Danilo Zrenjanin about 4 years ago
- Status changed from Feedback to Resolved
Tested with 0.15.7_20 FreeRADIUS version on SG-3100.
The issue has been solved. Ticket resolved.
Updated by Renato Botelho about 4 years ago
Michael Klein wrote:
Hi Renato, I tested the fix on both SG-3100's and it works very well. I'm glad that this issue has finally been resolved!
By the way, I'm sure you know that there is a $LOCKFILE variable defined in freeradius.inc, so there is no need to hardcode it and it would simply look like this:
[...]
Anyway, thank you so much for all your help! You can go ahead and close this ticket.
It's defined inside rc_start() so I opted to do the small change possible. Glad it worked!