"PHP Fatal error: Maximum execution time of 900 seconds exceeded in /etc/inc/util.inc on line 3728" after installing latest pfBlockerNG 3.2.0_12
-
Looks good:
>>> Installing pfSense-pkg-pfBlockerNG-devel... Updating pfSense-core repository catalogue... Fetching meta.conf: Fetching packagesite.pkg: pfSense-core repository is up to date. Updating pfSense repository catalogue... Fetching meta.conf: Fetching packagesite.pkg: pfSense repository is up to date. All repositories are up to date. The following 12 package(s) will be affected (of 0 checked): New packages to be INSTALLED: gnugrep: 3.11 [pfSense] grepcidr: 2.0 [pfSense] iprange: 1.0.4 [pfSense] jq: 1.7_1 [pfSense] lighttpd: 1.4.72 [pfSense] lua54: 5.4.6 [pfSense] nettle: 3.9.1 [pfSense] pfSense-pkg-pfBlockerNG-devel: 3.2.0_17 [pfSense] py311-maxminddb: 2.4.0 [pfSense] py311-sqlite3: 3.11.6_8 [pfSense] rsync: 3.2.7 [pfSense] xxhash: 0.8.2 [pfSense] Number of packages to be installed: 12 The process will require 18 MiB more space. 5 MiB to be downloaded. [1/12] Fetching py311-sqlite3-3.11.6_8.pkg: ... done [2/12] Fetching lighttpd-1.4.72.pkg: .......... done [3/12] Fetching gnugrep-3.11.pkg: .......... done [4/12] Fetching nettle-3.9.1.pkg: .......... done [5/12] Fetching lua54-5.4.6.pkg: .......... done [6/12] Fetching jq-1.7_1.pkg: .......... done [7/12] Fetching grepcidr-2.0.pkg: . done [8/12] Fetching xxhash-0.8.2.pkg: ...... done [9/12] Fetching iprange-1.0.4.pkg: .. done [10/12] Fetching rsync-3.2.7.pkg: .......... done [11/12] Fetching pfSense-pkg-pfBlockerNG-devel-3.2.0_17.pkg: ........ done [12/12] Fetching py311-maxminddb-2.4.0.pkg: .. done Checking integrity... done (0 conflicting) [1/12] Installing nettle-3.9.1... [1/12] Extracting nettle-3.9.1: .......... done [2/12] Installing lua54-5.4.6... [2/12] Extracting lua54-5.4.6: ......... done [3/12] Installing xxhash-0.8.2... [3/12] Extracting xxhash-0.8.2: .......... done [4/12] Installing py311-sqlite3-3.11.6_8... [4/12] Extracting py311-sqlite3-3.11.6_8: ........ done [5/12] Installing lighttpd-1.4.72... ===> Creating groups. Using existing group 'www'. ===> Creating users Using existing user 'www'. [5/12] Extracting lighttpd-1.4.72: .......... done [6/12] Installing gnugrep-3.11... [6/12] Extracting gnugrep-3.11: .......... done [7/12] Installing jq-1.7_1... [7/12] Extracting jq-1.7_1: .......... done [8/12] Installing grepcidr-2.0... [8/12] Extracting grepcidr-2.0: ..... done [9/12] Installing iprange-1.0.4... [9/12] Extracting iprange-1.0.4: ..... done [10/12] Installing rsync-3.2.7... [10/12] Extracting rsync-3.2.7: .......... done [11/12] Installing py311-maxminddb-2.4.0... [11/12] Extracting py311-maxminddb-2.4.0: .......... done [12/12] Installing pfSense-pkg-pfBlockerNG-devel-3.2.0_17... [12/12] Extracting pfSense-pkg-pfBlockerNG-devel-3.2.0_17: .......... done Saving updated package information... done. Loading package configuration... done. Configuring package components... Loading package instructions... Custom commands... Executing custom_php_install_command()... Rebuilding GeoIP tabs... done. Creating Firewall filter service... done. Renew Firewall filter executables... done. Starting Firewall filter Service... done. Creating DNSBL service... done. Renew DNSBL lighttpd executable... done. Creating DNSBL web server config ... done. Creating DNSBL Certificate... done. Starting DNSBL Service... done. Upgrading previous settings: Adv. Inbound firewall rule settings... no changes required ... done. OpenVPN/IPSec interface selections... no changes required ... done. Proofpoint/ET IQRisk settings... no changes required ... done. General Tab -> IP Tab settings... no changes required ... done. pfBlockerNGSuppress Alias -> IPv4 Suppression Customlist... no changes required ... done. Upgrading previous EasyLists to new format... no changes required ... done. Upgrading previous Firefox DoH to new format... no changes required ... done. MaxMind License Key configuration setting... no changes required ... done. Validating Widget cron settings... no changes required ... done. Upgrading... done Custom commands completed ... done. Executing custom_php_resync_config_command()...done. Menu items... done. Services... done. Writing configuration... done. ===== Message from grepcidr-2.0: -- ===> NOTICE: The grepcidr port currently does not have a maintainer. As a result, it is more likely to have unresolved issues, not be up-to-date, or even be removed in the future. To volunteer to maintain this port, please create an issue at: https://bugs.freebsd.org/bugzilla More information about port maintainership is available at: https://docs.freebsd.org/en/articles/contributing/#ports-contributing ===== Message from rsync-3.2.7: -- Some scripts provided by rsync, such as rrsync, require Python, which is not installed by default. >>> Cleaning up cache... done. Success
Bug reverted. Thanks @marcosm
Digging further commences....
-
@stephenw10 said in "PHP Fatal error: Maximum execution time of 900 seconds exceeded in /etc/inc/util.inc on line 3728" after installing latest pfBlockerNG 3.2.0_12:
Ha, yup. Testing _17....
If _17 has been reverted, we should expect a _18 in a near future ?
If so, I'll just wait for that release.Bug reverted. Thanks @marcosm
Nice, thanks everyone
-
@mcury said in "PHP Fatal error: Maximum execution time of 900 seconds exceeded in /etc/inc/util.inc on line 3728" after installing latest pfBlockerNG 3.2.0_12:
If _17 has been reverted, we should expect a _18
Too far, it was _15, then _16, now _17 is the one he is discussing:
@stephenw10 said in "PHP Fatal error: Maximum execution time of 900 seconds exceeded in /etc/inc/util.inc on line 3728" after installing latest pfBlockerNG 3.2.0_12:
[12/12] Extracting pfSense-pkg-pfBlockerNG-devel-3.2.0_17: .......... done
-
@SteveITS said in "PHP Fatal error: Maximum execution time of 900 seconds exceeded in /etc/inc/util.inc on line 3728" after installing latest pfBlockerNG 3.2.0_12:
Too far, it was _15, then _16, now _17 is the one he is discussing:
Yeap, that is clear as water to me, Steve.
-
@stephenw10 said in "PHP Fatal error: Maximum execution time of 900 seconds exceeded in /etc/inc/util.inc on line 3728" after installing latest pfBlockerNG 3.2.0_12:
Looks good:
Metoo !
_17 up and running
-
Version
3.2.0_17
has the changes reverted that caused the issue and is safe to upgrade to.That also means if you're upgrading pfSense to 24.03 and have pfBlockerNG-devel installed it will now complete correctly.
-
@stephenw10 Just upgraded to 3.2.0_17 on 2.7.2 and I'm still stuck at "Loading Package Instructions"
-
If you are upgrading from one of the effected versions, _15 or _16, you will still need to kill the DEINSTALL script that hangs there to allow it to continue.
-
@stephenw10 I killed the DEINSTALL process but the result is the same. I'm upgrading from _15.
-
Hmm, you killed the process ID shown in the ps output?
-
@stephenw10 said in "PHP Fatal error: Maximum execution time of 900 seconds exceeded in /etc/inc/util.inc on line 3728" after installing latest pfBlockerNG 3.2.0_12:
Hmm, you killed the process ID shown in the ps output?
yup
If I do a ps -aux | grep devel it comes back empty -
@rgrichster install non-devel then upgrade to devel. worked for me.
-
You will only see that process active whilst the pkg install/upgrade is trying to run. But killing the actual script should have worked. Killing the pkg-static process may have just aborted the whole install.
-
@stephenw10 I was able to install the non devel version and everything is working again. Guess I'll just stay here rather than upgrade to devel. Sounds like there really isn't a reason to use devel anymore.
-
@rgrichster I did the same thing, and yeah that's my impression as well . . . I don't think there's a compelling reason to switch back to devel?
-
on another pfsense box launching package manager still shows only _15 version ... is there a _17 to be pushed so we avoid having to perform the salvage operation like above?
-
_17 is pushed to both 24.03 and 2.7.2 repos. What pfSense version are you running? Which architecture if it's Plus?
-
@stephenw10 intel control box running 2.7.2, with _15 update bug already running - currently using package manager to view updates as \status\dashboard inaccessible, and it is still showing _15 for update.
is there a way to force package manager to jump to show _17, even for systems already stuck on _15 update?
-
Just to add a data point.
Two boxes running CE 2.7.2, one "live" system, one hot spare.
Both were previously on PFBLocker-NG 3.2.0_15, both updated yesterday although not at exactly the same time, the "live" system updated to 3.2.0_17 seemingly without issue, (phew) while the spare system got stuck with the update never completing in the GUI, although after I refreshed the GUI things seemed OK at first and I didn't look any further as it is not a live system.
However I got an alert a while later which ironically was a CPU temperature alert... and logging into the GUI I saw a crash report which included "PHP Fatal error: Maximum execution time of 900 seconds exceeded in /etc/inc/util.inc on line...." although I can't currently get back to the crash log as the Web UI has hung.
Two processes - pfblockerng.php cron and pfSense-pkg-pfBlockerNG-devel POST-INSTALL were stuck on 100% each so fully utilising 2 of the 4 cores on the system. In the htop output below I had tried to go to the package manager in the GUI, this caused the web interface processes to also get stuck in a high CPU loop as well making the Web UI unresponsive:
4374 root 107 0 140M 51460 R 43.3 0.3 18:39.17 php-fpm: pool nginx 40181 root 106 0 140M 50880 R 42.1 0.3 4:11.17 php-fpm: pool nginx 22471 root 106 0 70596 48840 R 41.1 0.3 23h50:37 //usr/local/bin/php -f //etc/rc.packages pfSense-pkg-pfBlockerNG-devel POST-INSTALL 399 root 107 0 140M 54144 R 41.0 0.3 19:04.01 php-fpm: pool nginx 81451 root 106 0 140M 50040 R 40.9 0.3 3:30.04 php-fpm: pool nginx 89567 root 107 0 70340 47936 R 40.3 0.3 7h48:53 /usr/local/bin/php /usr/local/www/pfblockerng/pfblockerng.php cron 46010 root 106 0 140M 50444 R 39.5 0.3 18:28.28 php-fpm: pool nginx 68826 root 106 0 140M 50920 R 39.1 0.3 18:40.88 php-fpm: pool nginx 21846 root 106 0 140M 52448 R 38.8 0.3 18:55.89 php-fpm: pool nginx
@stephenw10 As this is not a live system I can afford to do further forensics on it if it's helpful to figure out what went wrong, before attempting a fix ? If no further info is required to help troubleshoot the cause I will attempt a manual fix.
-
As seen elsewhere :
kill 89567
and then check if process 22471 continues finishing its job.