Freeradius 2 doesn't start after upgrade to PFS 2.2
-
All the technical details are way beyond my knowledge. Since the last upgrade the Freeradius problems are gone and Freeradius is (re)starting as it should after a reboot of pfSense. Great I don't have to start it manually anymore.
-
I'm on pfSense 2.2.6 and freeradius2 Package 1.6.19, which both are the newest Versions.
Since this is a Race Condition the Problem will hit only some users. It depends on the Hardware you are running pfSense on.I like to see this Problem solved in the freeradius2 Package, because now I have to manually patch this every time a new pfSense Version or freeradius2 Package is installed.
I can create a Pull Request against freeradius.inc on https://github.com/pfsense/pfsense-packages, if someone give me a hint howto get something out of the rc_ Functions.
-
I got it fixed when I went to "Packages" tab and reinstalled Freeradius2 by pressing on its [pkg] button.
I run PFS 2.2.6 and had the same problem and reinstalling the packadge solved the problem.
-
The correct solution may be to make pfsense not try to start and stop service at the same time.
Checking PIDs and lockfiles seems like a workaround.
Another workaround i found is to add "sleep 10" at the beginning of rc_start so all rc_stops are finished before rc_starts. (but this may fail if rc_stops take more than 10s)
@bbaumer:if someone give me a hint howto get something out of the rc_ Functions.
What do you mean?
-
To prevent radiusd being startet multiple times the code in rc_start was added by https://redmine.pfsense.org/issues/4337. This was then merged in https://github.com/pfsense/pfsense-packages/pull/839/files
Like SmileyAU suggestet /usr/local/etc/rc.d/radiusd.sh ist started with the Argument start and stop multiple times. This is done by pfSctl -c 'service reload packages'.
This leads to a RaceCondition where rc_start is still running and rc_stop is called. For me this leads to a always stopped radiusd.I fixed this by checking the LOCKFILE and the PIDFILE in rc_stop.
#!/bin/sh # This file was automatically generated # by the pfSense service handler. SERVICENAME="radiusd" LOCKFILE="/tmp/${SERVICENAME}_start.lock" PIDFILE="/var/run/${SERVICENAME}.pid" rc_start() { # prevent this part of script from running in parallel if ( set -o noclobber; echo "$$" > "$LOCKFILE") 2> /dev/null; then # make sure lock file is removed even if script is terminated trap 'rm -f "$LOCKFILE"; exit $?' INT TERM EXIT /usr/pbi/freeradius-amd64/local/etc/rc.d/radiusd onestart # try to wait until the service starts if [ ! -f "$PIDFILE" ]; then echo "$SERVICENAME.sh: PID file was not found" for i in 1 2 3 4 5; do if [ -f "$PIDFILE" ]; then echo "$SERVICENAME.sh: Service started PID: `cat $PIDFILE`" break else echo "$SERVICENAME.sh: Waiting 0.5 seconds" sleep 0.5 fi done else echo "$SERVICENAME.sh: Service running PID: `cat $PIDFILE`" fi rm -f "$LOCKFILE" trap - INT TERM EXIT else echo "$SERVICENAME.sh: Cannot continue at this moment, this script is already trying to start service PID: $(cat $LOCKFILE)" fi } rc_stop() { # Don't stop if service start is in progress # pfSctl -c 'service reload packages' call start and stop multiple times if [ ! -f "$LOCKFILE" -a -f "$PIDFILE" ]; then /usr/pbi/freeradius-amd64/local/etc/rc.d/radiusd onestop fi } case $1 in start) rc_start ;; stop) rc_stop ;; restart) rc_stop rc_start ;; esacThanks, this works, please someone commit this code in so others won't have this issue. Whenever the:
"check_reload_status: Starting packages"
initiates, it'll restart the radius and the race condition occurs, the checking for PID on rc_stop makes this problem go away.
-
I got it fixed when I went to "Packages" tab and reinstalled Freeradius2 by pressing on its [pkg] button.
I run PFS 2.2.6 and had the same problem and reinstalling the packadge solved the problem.
This works as well, unsure why…
Also the previous post on the fix, it works but then you can never stop it, since the PID file is there when it's running. Not sure how to 100% prevent this issue.
-
Same problem here on 2.3 release, service doesn't start in 90% of the cases on reboot….
As suggested by bbaumer just edit /usr/local/etc/rc.d/radiusd.sh by this way to solve the situation :) :
#!/bin/sh # This file was automatically generated # by the pfSense service handler. SERVICENAME="radiusd" LOCKFILE="/tmp/${SERVICENAME}_start.lock" PIDFILE="/var/run/${SERVICENAME}.pid" rc_start() { # prevent this part of script from running in parallel if ( set -o noclobber; echo "$$" > "$LOCKFILE") 2> /dev/null; then # make sure lock file is removed even if script is terminated trap 'rm -f "$LOCKFILE"; exit $?' INT TERM EXIT /usr/local/etc/rc.d/radiusd onestart # try to wait until the service starts if [ ! -f "$PIDFILE" ]; then echo "$SERVICENAME.sh: PID file was not found" for i in 1 2 3 4 5; do if [ -f "$PIDFILE" ]; then echo "$SERVICENAME.sh: Service started PID: `cat $PIDFILE`" break else echo "$SERVICENAME.sh: Waiting 0.5 seconds" sleep 0.5 fi done else echo "$SERVICENAME.sh: Service running PID: `cat $PIDFILE`" fi rm -f "$LOCKFILE" trap - INT TERM EXIT else echo "$SERVICENAME.sh: Cannot continue at this moment, this script is already trying to start service PID: $(cat $LOCKFILE)" fi } rc_stop() { # Don't stop if service start is in progress # pfSctl -c 'service reload packages' call start and stop multiple times if [ ! -f "$LOCKFILE" -a -f "$PIDFILE" ]; then /usr/local/etc/rc.d/radiusd onestop fi } case $1 in start) rc_start ;; stop) rc_stop ;; restart) rc_stop rc_start ;; esac -
All madness hopefully fixed here:
https://github.com/pfsense/FreeBSD-ports/pull/267 (merged in 1.7.5)
https://github.com/pfsense/FreeBSD-ports/pull/268 (pending) -
@bbaumer I submitted a bug report regarding this issue. Unfortunately, it got rejected because he was unable to recreate the issue in his testing environment. Check this for more details:
[https://redmine.pfsense.org/issues/11013](link url)
Almost 5 years later, this issue still exists under certain conditions and they refuse to add the one conditional statement that would fix it for those it affects even though it wouldn't cause any problems for the rest of their users.
-
UPDATE 11/02/2020:
This issue has finally been resolved in FreeRADIUS package version 0.15.7_20
Thank you Renato!
