"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

Gertjan

@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

stephenw10

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.

rgrichster

@stephenw10 Just upgraded to 3.2.0_17 on 2.7.2 and I'm still stuck at "Loading Package Instructions"

stephenw10

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.

rgrichster

@stephenw10 I killed the DEINSTALL process but the result is the same. I'm upgrading from _15.

stephenw10

Hmm, you killed the process ID shown in the ps output?

rgrichster

@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

incith

@rgrichster install non-devel then upgrade to devel. worked for me.

stephenw10

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.

rgrichster

@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.

TheNarc

@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?

wufwuf

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?

stephenw10

_17 is pushed to both 24.03 and 2.7.2 repos. What pfSense version are you running? Which architecture if it's Plus?

wufwuf

@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?

DBMandrake

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.

Gertjan

@DBMandrake

As seen elsewhere :

kill 89567

and then check if process 22471 continues finishing its job.

DBMandrake

@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)

DBMandrake

@DBMandrake Checking system.log I can see I started the update at 10:47am: (UK time)

Sep 24 10:46:58 pfSense3 lighttpd_pfb[4067]: [pfBlockerNG] DNSBL Webserver stopped
Sep 24 10:46:58 pfSense3 tail_pfb[6074]: [pfBlockerNG] Firewall Filter Service stopped
Sep 24 10:46:58 pfSense3 php_pfb[6603]: [pfBlockerNG] filterlog daemon stopped
Sep 24 10:46:58 pfSense3 php[2869]: /etc/rc.packages: Configuration Change: (system): Intermediate config write during package removal for pfBlockerNG-devel.
Sep 24 10:46:58 pfSense3 check_reload_status[439]: Syncing firewall
Sep 24 10:46:58 pfSense3 php[2869]: /etc/rc.packages: Configuration Change: (system): pfBlockerNG: saving Unbound custom options
Sep 24 10:46:58 pfSense3 check_reload_status[439]: Syncing firewall
Sep 24 10:46:58 pfSense3 php[2869]: /etc/rc.packages: Configuration Change: (system): pfBlockerNG: saving DNSBL changes
Sep 24 10:46:58 pfSense3 snort[40410]: Received notification of an IP address change on interface lo0.
Sep 24 10:46:58 pfSense3 snort[40410]: Deleted address 10.10.10.1 from automatic interface IP Pass List for Legacy Blocking Mode.
Sep 24 10:47:00 pfSense3 check_reload_status[439]: Reloading filter
Sep 24 10:47:00 pfSense3 php[2869]: [pfBlockerNG] Restarting firewall filter daemon
Sep 24 10:47:00 pfSense3 php[22471]: //etc/rc.packages: Beginning package installation for pfBlockerNG-devel .
Sep 24 10:47:00 pfSense3 php[22471]: //etc/rc.packages: Configuration Change: (system): Intermediate config write during package install for pfBlockerNG-devel.
Sep 24 10:47:00 pfSense3 check_reload_status[439]: Syncing firewall

And there is NOTHING in the log after this relating to the package installation, in fact the next thing in the log is at 4am the following day from the auto config backup service.

By the way the process 22471 is still on 100% and I don't think it's going to complete...

Gertjan

@DBMandrake

kill also 22471

and as showed by @stephenw10 (see above) :

pkg remove pfSense-pkg-pfBlockerNG

so pfSense doesn't try to re installed the already downloaded package and gets blocked gain.

DBMandrake

@Gertjan It's pkg remove pfSense-pkg-pfBlockerNG-devel as it's the development package.

Manually removing it and reinstalling it has fixed it.

I'm wondering if I should go back to the non-devel version - I've been on the devel version of pfBlockerNG forever because the standard package was a full major version behind for a long time, and was lacking a feature I needed, but they're both 3.2.xx now.

I'm guessing I would have to note down my configuration and manually reconfigure if I did this though as the system would treat this as a different package altogether with its own configuration ?