"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
-
@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_17has 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 89567and then check if process 22471 continues finishing its job.
-
@Gertjan Killed. how long should I give it ?
The POST-INSTALL process is still on 100%.
However judging by my CPU graph, the cron process got stuck in a 100% loop AFTER the install process did... the install process was already sitting at 100% CPU for hours before that.
(Cron runs at 3am)
