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.


  • LAYER 8 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.



  • Enter following command in PfSense Console to restart the Php-Fpm service after OS version upgrade from 2.4.3 to 2.4.4

    PFSense Version 2.4.3 uses Php version 5.6 and PFSense Version 2.4.4 uses Php version 7.2 as well as PFSense version 2.4.3 uses FreeBSD version 11.1 and PFSense Version 2.4.4 uses FreeBSD version 11.2

    What I did to resolve the PHP errors on update is:

    1. SSH to PFSense Console and Enter the following command to restart PHP Service:

    service php-fpm onestart

    I restarted this service because, some tasks might be running on the older PHP version, so the errors are there.
    Most important thing you should keep in mind is that you should be authorized to restart the service.

    1. If you are not able to SSH to PfSense console then manually connect VGA monitor and a compatible keyboard to the PfSense device --> login as root/sudo user --> run the above command

    You can go through following url to check how to connect monitor and keyboard to PfSense Device:
    https://www.netgate.com/docs/pfsense/solutions/xg-1541/connect-to-console.html



  • @pankajkumawat79-0 When I tried to install ACME pkg on PFSense version 2.4.3, it deleted some of the php files resulting no access to webgui.

    As ACME pkg required php 7.2 and my PFSense version 2.4.3 was running on PHP 5.X, it tried to update the PHP resulting in a big mess up.

    What I did to fix this problem is to reinstall all packages aggressively.

    "pkg update -f"
    "pkg upgrade -f"

    Their was a new PFSense version 2.4.4 available which runs on PHP 7.2.

    It solved my issue of webgui access.

    Still, some of the controls were not accessible for me in the PFSense webconsole, so I tried to run the following command in the console shell

    "service php-fnm onestart"

    by connecting a monitor and a keyboard to the PFSense hardware device directly.

    It solved my issue and now PFSense is updated to latest version 2.4.4.



  • RE: upgrading Netgate SG-8860 from 2.4.3_1 to 2.4.4_1

    First update attempt apparently downloaded a bunch of files, reported as failed, and indicated that 2.4.4_1 was available.

    So, I tried to update again.
    Second try succeeded after several minutes.

    However, when I logged back in, I did get a long crash report listing many PHP errors:

    Starting lines:

    "Crash report details:

    PHP Errors:
    [22-Dec-2018 13:44:38 UTC] PHP Warning: Failed loading Zend extension 'opcache.so' ..."

    After finding this page and reading and mostly understanding Gertjan's comments, and since it's a weekend and I can, I simply Rebooted (yes, I know how to login to the console and run a command line to just restart the service, but I thought it'd probably be a good idea to do a reboot anyway. disclaimer: there are risks and your mileage may vary, I'm generally aware of mine and what works for me may not work for you.)

    No errors after reboot.

    Thanks to you geniuses who keep making this relatively easier and user friendly.

    Just thought I'd add my experience to the rest listed.