PHP Errors after upgrade to 2.4.4



  • I upgraded from 2.4.3 to 2.4.4 and I am now receiving PHP errors and I am not sure where they are coming from. A sample of the error is below. Any help is much appreciated.

    [24-Sep-2018 23:55:09 UTC] PHP Warning: Failed loading Zend extension 'opcache.so' (tried: /usr/local/lib/php/20131226/opcache.so (/usr/local/lib/php/20131226/opcache.so: Undefined symbol "zend_opcode_handlers"), /usr/local/lib/php/20131226/opcache.so.so (Cannot open "/usr/local/lib/php/20131226/opcache.so.so")) in Unknown on line 0
    [24-Sep-2018 23:55:09 UTC] PHP Warning: PHP Startup: Unable to load dynamic library 'session.so' (tried: /usr/local/lib/php/20131226/session.so (/usr/local/lib/php/20131226/session.so: Undefined symbol "zval_used_for_init"), /usr/local/lib/php/20131226/session.so.so (Cannot open "/usr/local/lib/php/20131226/session.so.so")) in Unknown on line 0
    [24-Sep-2018 23:55:09 UTC] PHP Warning: PHP Startup: bcmath: Unable to initialize module
    Module compiled with module API=20131226
    PHP compiled with module API=20170718
    These options need to match
    in Unknown on line 0



  • Did the same upgrade and got the same error result.

    Here's a snippet from my PHP_errors.log:

    [25-Sep-2018 03:03:14 UTC] PHP Warning: Failed loading Zend extension 'opcache.so' (tried: /usr/local/lib/php/20131226/opcache.so (/usr/local/lib/php/20131226/opcache.so: Undefined symbol "zend_opcode_handlers"), /usr/local/lib/php/20131226/opcache.so.so (Cannot open "/usr/local/lib/php/20131226/opcache.so.so")) in Unknown on line 0
    [25-Sep-2018 03:03:14 UTC] PHP Warning: PHP Startup: Unable to load dynamic library 'session.so' (tried: /usr/local/lib/php/20131226/session.so (/usr/local/lib/php/20131226/session.so: Undefined symbol "zval_used_for_init"), /usr/local/lib/php/20131226/session.so.so (Cannot open "/usr/local/lib/php/20131226/session.so.so")) in Unknown on line 0
    [25-Sep-2018 03:03:14 UTC] PHP Warning: PHP Startup: bcmath: Unable to initialize module
    Module compiled with module API=20131226
    PHP compiled with module API=20170718
    These options need to match
    in Unknown on line 0 .........



  • Same here. I don't notice any obvious impact, but this crash seems to reoccur periodically.



  • Got the same Php errors here after I upgraded pfBlockerNG but before upgrading pfSense to 2.4.4.



  • ?
    We all read https://www.netgate.com/docs/pfsense/install/upgrade-guide.html#version-specific-notes before upgrading, right ?

    What happens is that during the upgrade, PHP Lib directory /usr/local/lib/php/20131226 is destroyed to make place for /usr/local/lib/php/20170718
    Or, during the upgrade, some tasks (most GUI based maintenance tasks) still using PHP 5.2 (pfSense 2.4.3....) are still running. They die - they maybe should have been killed anyway, but hey, we want to see, among others, the upgrade progress in GUI, right ;)

    So, consider it this way : it would be a bad things if these errors didn't show up ☺



  • I did read that, and in particular the following:

    "These errors are primarily seen on the console as the upgrade is applied, but may appear in a crash report once the upgrade completes. In nearly all cases these errors are a harmless side effect of the changes between FreeBSD 11.1 and 11.2 and between PHP 5.6 and PHP 7.2."

    It wasn't clear from that though whether recurring crash reports would be expected. Although I know that another section of that same post suggested that certain configurations may result in more PHP errors. In any case, I guess we should maybe give it some time and or reboot again before considering it a real issue?



  • PHP is the engin that drives among others the GUI, and errors aren't shown the 'raw' way when they happen.
    Much of the PHP code also runs without any user interaction, as it is not related to the GUI.

    PHP is instructed to log all errors, and when the user logs into the GUI, and a PHP error happened in the past, it is shown as a "crash".

    The crash report collector reports kernel crashed but also these less important PHP failures.


  • Netgate

    If a PHP error occurs again after clearing it initially after upgrading, please report. It is probable that some things were missed in the bajillions of permutations of pfSense configuration and package options.



  • Okay. FYI: we have not upgraded to 2.4.4. We're still at 2.4.3. We just upgraded the pfBlockerNG and we started getting the errors already. So we uninstalled pfBlockerNG and it stated that it was successful but it's still there in the Firewall > pfBlockerNG. So we installed it again and we're still getting the php errors. We did submit the log so hope it helps.



  • @noel-alanguilan said in PHP Errors after upgrade to 2.4.4:

    we have not upgraded to 2.4.4. We're still at 2.4.3.

    So, your message is for Home pfSense Packages pfBlockerNG, and related to 2.4.4 or this thread ...



  • ;) one of solution :(

    1. ssh to pfsense
    2. cd /usr/local/lib/php/
    3. ln -s 20170718/ 20131226

    for pfBlockerNG

    1. vi /usr/local/www/pkg_edit.php
    2. in line 913 delete '|'


  • I had the same issue after install pfBlockerNG on pfsense 2.4.3, during the installation pfsense gui was blocked, now I have many error of php in my console.

    So I reverted the config thanks config history, then I upgraded pfsense to 2.4.4 and the I installed new pfblocker and everythings was gone well.
    thanks



  • @derelict said in PHP Errors after upgrade to 2.4.4:

    If a PHP error occurs again after clearing it initially after upgrading, please report. It is probable that some things were missed in the bajillions of permutations of pfSense configuration and package options.

    For me, it happened two times: One right after upgrading to 2.4.4 (18:30) and the other one almost six hours later (00:01).



  • pfBlockerNG appears to be the common thread here; I have it installed as well. I did not upgrade the pfBlockerNG package before the upgrade from 2.4.3 to 2.4.4, but it was upgraded in the process of the upgrade. I've attached the crash log of one of the recurring crashes in case it's useful.
    PHP_Crash_Report.txt


  • Rebel Alliance Developer Netgate

    If you attempted to upgrade a package on 2.4.3, it pulled the package from 2.4.4 instead because you were set to track stable updates and didn't upgrade first.

    https://redmine.pfsense.org/issues/8938

    We've added a safety belt to prevent that kind of foot shooting in the future. If you run pkg-static upgrade pfSense-upgrade it should pull in a new copy of the update script that will help prevent that from happening.

    In the meantime, the best fix is to run the rest of the upgrade. Do not try to stay on 2.4.3-p1.



  • At least in my case, I'm pretty sure that my PHP errors coincide with an hourly cron job that attempts to start the pfb_filter service that's part of pfBlockerNG. I say this because if I attempt to start that service manually, it provokes the exact same set of errors. I did not attempt to manually upgrade any of my packages prior to running the 2.4.3 -> 2.4.4 upgrade.
    I've been in touch with BBCan17 and linked him to this thread too, since this seems potentially all related to the pfBlockerNG package.



  • @thenarc said in PHP Errors after upgrade to 2.4.4:

    since this seems potentially all related to the pfBlockerNG package

    Noop, see the link @jimp mentioned. Same thing happens when upgrading the recently updated package acme.
    The most recent acme package also depends on PHP 7.2.



  • As a datapoint, just took a new SG-1000, configured LAN/WAN LAN-DHCP range no additional packages, and then initiated update.
    After restart after the same issues as OP, and no commands on console working apart from shell/restart

    Have spare SG-1000 and will recover once the issue is fixed.



  • Just to add data I do have PfBlocker, Service Watchdog, UPS and Snort installed but the error log doesnt mention any of these add-on's. For troubleshooting I uninstalled PfBlocker and installed the Dlevel version and received this:

    Fatal error: Uncaught Error: Call to undefined function pfb_alerts_default_page() in /usr/local/www/pfblockerng/pfblockerng_general.php:96 Stack trace: #0 {main} thrown in /usr/local/www/pfblockerng/pfblockerng_general.php on line 96 PHP ERROR: Type: 1, File: /usr/local/www/pfblockerng/pfblockerng_general.php, Line: 96, Message: Uncaught Error: Call to undefined function pfb_alerts_default_page() in /usr/local/www/pfblockerng/pfblockerng_general.php:96 Stack trace: #0 {main} thrown

    So I uninstalled the Dlevel and I am back to using the regular at least it works even though its creating all sorts of errors.



  • @jimp said in PHP Errors after upgrade to 2.4.4:

    pkg-static upgrade pfSense-upgrade

    Seen https://redmine.pfsense.org/issues/8938 and ran above command. But it looks like I can't get out of that bad state triggered by having attempted upgrade of acme package before spotting there was an important system update.

    What am I left with?
    Is there a way to recover from this situation other than zapping the system and rebuilding anew?



  • @lvrmsc said in PHP Errors after upgrade to 2.4.4:

    @jimp said in PHP Errors after upgrade to 2.4.4:

    pkg-static upgrade pfSense-upgrade

    Seen https://redmine.pfsense.org/issues/8938 and ran above command. But it looks like I can't get out of that bad state triggered by having attempted upgrade of acme package before spotting there was an important system update.

    What am I left with?
    Is there a way to recover from this situation other than zapping the system and rebuilding anew?

    I finally could run pfSense-upgrade from an ssh console and I apparently got out of the hole.



  • @gertjan Not exactly. I looked over the warnings and the report and it's all related to php7.2. There was no mention of pfBlockerNG and it so happens that that package (pfBlocker) was the only one I updated.