pfSense

Re: execution timeouts
I did some research and testing on this, as I have slow links in places (128kbps) and some package downloads or firmware upgrades certainly take more than 30 minutes, and sometimes more than an hour.

set_time_limit is actually NOT a php.ini parameter. It is a PHP function. To avoid future confusion, this can be removed from rc.php_ini_setup. max_execution_time is the php.ini parameter, set_time_limit function modifies this for a script at run time.

I tested by:
a) Modify rc.php_ini_setup, set_time_limit = 1, reboot. Install Cron, OpenVPN Client Export Utility and Squid3 packages (a variation of sizes, download times, extract times...). All goes fine. Remove the packages.

b) Modify rc.php_ini_setup, remove set_time_limit = 1, reboot. Install Cron, OpenVPN Client Export Utility and Squid3 packages. All goes fine. Remove the packages.

So set_time_limit in php.ini is not effecting PHP. Note that online comments on php.ini inidicate that it is not parsed for errors - extra "parameters" and their settings can be put in it and they are simply ignored.

Re: execution timeouts - max_execution_time and max_input_time
I reduced these to see what would happen for package installs.
At silly values:
max_execution_time = 2
max_input_time = 4
The system gets errors at boot, so it doesn't even come up - have to use the serial console to put things back.
[22-Jul-2012 07:39:57 UTC] PHP Fatal error: Maximum execution time of 2 seconds exceeded in /etc/inc/xmlparse.inc on line 73

Set the following:
max_execution_time = 5
max_input_time = 10
Reboot
System boots OK
Installed Cron, OpenVPN Client Export Utility and Squid3
The PBI downloads are much longer than 5 or 10 seconds. The PBI extracts also taker longer than 5 or 10 seconds. But it all works fine.
The PHP doc implies that these time limits are CPU time executing PHP - they don't include time doing/waiting for system events (file I/O etc). There is an indication that the elapsed time might be used in Windows (IIS).
I guess the package downloading code is putting progress updates on the GUI every now and then, also restarting any timer.
Anyway, the limits set (1800, 3600 seconds) I think will catch PHP code that goes into a loop and chews up 30/60 minutes of CPU time. A download that hangs or is extremely slow might not ever be caught by these timers, or would takes ages to accumulate the CPU time.
I don't think any change is really needed (although the system should work fine with a limit of a few minutes) - just thought I would document my testing for the future.

Small edit of my previous post: the limits are actually set to (900, 1800) seconds (15/30 minutes) and work fine like this.
When the next build is available I will try a download of the 70+MB on my 128kbps link and report the result.

For info, the current full text of the default php.ini is available at:
http://svn.php.net/viewvc/php/php-src/trunk/php.ini-production?view=co

Used a slow link to do a Firmware Upgrade from the Sat 21 July build to:
2.1-BETA0 (i386)
built on Sun Jul 22 13:36:03 EDT 2012
FreeBSD 8.3-RELEASE-p3

It took 55 minutes to download. All worked fine - no timeouts.

Phillip Davis wrote:

Used a slow link to do a Firmware Upgrade from the Sat 21 July build to:
2.1-BETA0 (i386)
built on Sun Jul 22 13:36:03 EDT 2012
FreeBSD 8.3-RELEASE-p3

It took 55 minutes to download. All worked fine - no timeouts.

That is good to hear! That was one thing that concerned me. Thanks for testing.