rc.stop_packages causes reboot to only works from SSH, not from Web interface
As reported in the forum (http://forum.pfsense.org/index.php/topic,37258.0.html), the reboot feature doesn't work from the Web interface. Need to either use the console or SSH to reboot pfSense.
Running version : 30 May / nanobsd 2g.
#2 Updated by Perry Mason over 5 years ago
I can confirm on snapshot May 30 11:53:52 nanobsd 4G when I remove rc.stop_packages https://github.com/bsdperimeter/pfsense/commit/a1b86994a0b2895d0d81fb12f680639bfc1d9b42 I can reboot from gui
#5 Updated by Evgeny Yurchenko over 5 years ago
It seems that this is related to bug in php http://bugs.php.net/bug.php?id=11430 "Impossible to execute .php from inside .php by using exec()"
When I replaced
in Ermal's commit with
the problem disappeared with stop_packages being executed first. If you are ok with this solution I can commit it.
#7 Updated by Bill Marquette over 5 years ago
The php.net bug is a decade old. While include() may 'fix' this, IMHO it really obfuscates what it's trying to do and I'm not sure it's the right fix. I also notice that the shebang line includes '-f' which seems a tad odd (and in most of our scripts so it's unlikely at issue), not sure where we picked that up from.
Does mwexec("/usr/local/bin/php -f /etc/rc.stop_packages"); work any better?
#9 Updated by Evgeny Yurchenko over 5 years ago
I've spent some time trying to understand why we get three processes rc.stop_packages after clicking reboot from gui:
[2.0-RC2][email@example.com]/root(9): ps -eaxfj | grep stop_
ps: Process environment requires procfs(5)
root 17981 41684 17981 17981 0 Ss ?? 0:00.03 /usr/local/bin/php -f /etc/rc.stop_packages
root 18183 17981 17981 17981 0 S ?? 0:00.00 /usr/local/bin/php -f /etc/rc.stop_packages
root 18335 17981 17981 17981 0 S ?? 0:00.00 /usr/local/bin/php -f /etc/rc.stop_packages
Not being able to find reasonable explanation and after making sure the same call works perfectly when you run it from console I asked google. Note that the first process parents two others and this correlates very well with what is described in article mentioned above, this is why I thought that this is probably related to this bug in php.
BTW I could not find any other place in pfSense when we do similar call (/etc/rc.something from php).
Totally agree that include is very ugly 'solution' in this case, that is why I haven't tried to commit this 'fix'.
And finally - anyway we have to fix this (remove this call? write other function stopping packages?)
#11 Updated by Warren Baker over 5 years ago
Changing rc.stop_packages to a shell script works. Which is a small trivial change and the following works for me:
#!/bin/sh /usr/local/bin/php -q <<ENDPHP <?php require_once("config.inc"); require_once("functions.inc"); require_once("filter.inc"); require_once("shaper.inc"); require_once("captiveportal.inc"); require_once("pkg-utils.inc"); require_once("pfsense-utils.inc"); require_once("service-utils.inc"); ... .. . /* The rest of the current rc.stop_packages php code HERE */ ?> ENDPHP
I can commit this change, unless someone else sees a potential problem with this approach?
#15 Updated by Peter Baumann over 5 years ago
Just want to let you know that I use many pfSense 2.0-RC3 firewalls here for testing.
I use amd64 and i386 in XenServer vm and ALIX boards.
Today I had to do some config changes on all these firewalls and I tried to reboot the firewalls over the web interface, this was working without any problems.
At the moment I use
built on Thu Jul 21 22:37:35 EDT 2011
built on Wed Jul 20 19:51:58 EDT 2011
#16 Updated by Jim Pingle about 5 years ago
- Subject changed from Reboot only works from SSH but not from Web interface to rc.stop_packages causes reboot to only works from SSH, not from Web interface
rc.stop_packages is currently disabled which is why reboots are still working now.
Since the upgrade to PHP 5.2.17 I figured it was worth trying this again, and I found that neither mwexec nor exec work for calling /etc/rc.stop_packages.
Warren's method from #11 works, that should be fine to do.