pfSense

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

I can confirm that I have this issue using 2.0-RC2 (i386) Mon May 30 11:06:53.
Tried to reboot from reboot.php. Webgui was no longer responding. Logged in with ssh restarted the webCon. WebGUI would not respond. Rebooted from ssh.

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
+ mwexec("/etc/rc.stop_packages");
in Ermal's commit with
+ include("/etc/rc.stop_packages");
the problem disappeared with stop_packages being executed first. If you are ok with this solution I can commit it.

#5 Solution works for me as well, for me please commit ...

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?

I've spent some time trying to understand why we get three processes rc.stop_packages after clicking reboot from gui:
[2.0-RC2][admin@pfsense.localdomain]/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?)

Forgot to mention: mwexec("/usr/local/bin/php -f /etc/rc.stop_packages"); does not work either.

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?

I will look at this a bit since its related to some other hangs that happen at times.

For the moment I disabled the package stop on reboot.

Though after sleeping on it, I remembered a similar problem I hit before. I wonder if it's the same root cause as #602

Just tested
exec("/etc/rc.reboot");
works ok. Probably because /etc/rc.reboot does not contain php code.

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

2.0-RC3 (amd64)
built on Thu Jul 21 22:37:35 EDT 2011

and

2.0-RC3 (i386)
built on Wed Jul 20 19:51:58 EDT 2011

Peter

Applied in changeset 0124456b0c4d602adea538cee35fc67c977e9f2e.