Special case Ubuntu PHP versions for some system_requirements() warnings

Just been caught by this too. Upgraded from Ubuntu 20.04.06 LTS > 22.04.2 LTS - then was greeted by the warning on the status page.

My php reports:

HP 8.1.2-1ubuntu2.11 (cli) (built: Feb 22 2023 22:56:18) (NTS)
Copyright (c) The PHP Group
Zend Engine v4.1.2, Copyright (c) Zend Technologies
    with Zend OPcache v8.1.2-1ubuntu2.11, Copyright (c), by Zend Technologies

Hoping that by now the bug has been fixed by the Ubuntu team - and made it into the release number 11.

How do we check for the opcache error in question - log files?

I just hit the opcache bug using PHP 8.1.2-1ubuntu2.11

The system was running fine a few days after upgrading to Ubuntu 22.04 and then sudenly I started getting the tons of Class "Drupal\Core\Utility\Error" not found in _drupal_error_handler_real errors.

So I'm pretty sure that probablem wasn't completely fixed in Ubuntu.
Or I have some different case but I can't find anything similar except 📌 Status report should warn about OPcache bug in PHP 8.1.0 to 8.1.5 Fixed and this issue thread.

I've been running Ubuntu 22.04.06 for several months now - with the stock PHP running - and our log files are all clear. Could it be something else causing the error @artem_sylchuk ?

Hard to say, I don’t use any software out of ubuntu repository, everything standard.
However I’m running php-fpm.
I had to disable opcache for now and not sure what else I can check to be sure that I’m having the same problem that was supposed to be fixed in Ubuntu, don’t think that it had reliable steps for reproducing.

Same as #24

newaytech, maheve, and artem_sylchuk, can you let us know the environment you're running PHP in? Are you using it with mod-php, php-fpm, or something different? Thanks

Hey @Brandon-, not sure what do you mean by environment, but as I said I run php using php-fpm.
No exernal PPAs, everything standard and as far as I know no special tuning/adjustments were made.
Will be happy to share any other details if needed.

Hey @brandon - thanks for checking in. Our setup is:

10:10 AM root@web2:#~ php -v

PHP 8.1.2-1ubuntu2.13 (cli) (built: Jun 28 2023 14:01:49) (NTS)
Copyright (c) The PHP Group
Zend Engine v4.1.2, Copyright (c) Zend Technologies
with Zend OPcache v8.1.2-1ubuntu2.13, Copyright (c), by Zend Technologies

10:11 AM root@web2:#~ apachectl status

Apache Server Status for localhost (via 127.0.0.1)

Server Version: Apache/2.4.52 (Ubuntu) OpenSSL/3.0.2
Server MPM: prefork
Server Built: 2023-03-01T22:43:55
__________________________________________________________________

Current Time: Friday, 07-Jul-2023 10:11:14 BST
Restart Time: Wednesday, 05-Jul-2023 13:36:40 BST
Parent Server Config. Generation: 11
Parent Server MPM Generation: 10
Server uptime: 1 day 20 hours 34 minutes 33 seconds
Server load: 0.05 0.07 0.08
Total accesses: 98105 - Total Traffic: 636.4 MB - Total Duration:
5193991

CPU Usage: u264.91 s114.04 cu6035.18 cs1408.11 - 4.87% CPU load
.611 requests/sec - 4158 B/second - 6.6 kB/request - 52.9432 ms/request

1 requests currently being processed, 6 idle workers

I did try php-fpm - but on the apache bench performance tests I ran - it was slower than out of the box PHP - so kept the install simple.

Good news - it was fixed in recent 8.1.22 https://github.com/php/php-src/issues/11522

But will Ubuntu backport this patch is not clear

@andypost: You mean backporting "Fix GH-11522: PHP version check fails with '-' separator"?
Thought the problem is just we still have rare cases of the OPcache issue without a reproducer.
After providing Athos from Canonical the backport he also fixed the version as verified by @mfb
https://bugs.launchpad.net/ubuntu/+source/php8.1/+bug/1989196
https://www.drupal.org/project/drupal/issues/3307248#comment-14819048 📌 Special case Ubuntu PHP versions for some system_requirements() warnings Active

I did check on Ubuntu lunar

$ php -r 'var_dump(version_compare(phpversion(), "8.1.6"));'
int(1)

but on jammy

Processing triggers for php8.1-cli (8.1.2-1ubuntu2.13) ...
root@scw-runner:~# php -r 'var_dump(version_compare(phpversion(), "8.1.6"));'
int(-1)

@andypost Maybe we misunderstand you but jammy is at 8.1.2 plus extra downstream patches.
The behavior from version_compare seems fine on jammy with your test case provided or not?

test@jammy:~# php --version
PHP 8.1.2-1ubuntu2.13 (cli) (built: Jun 28 2023 14:01:49) (NTS)
Copyright (c) The PHP Group
Zend Engine v4.1.2, Copyright (c) Zend Technologies
    with Zend OPcache v8.1.2-1ubuntu2.13, Copyright (c), by Zend Technologies
test@jammy:~# php -r 'var_dump(version_compare(phpversion(), "8.1.6"));'
int(-1)
test@jammy:~# php -r 'var_dump(version_compare(phpversion(), "8.1.2"));'
int(1)
test@jammy:~# php -r 'var_dump(version_compare(phpversion(), "8.1.2-1ubuntu2.13"));'
int(0)

"By default, version_compare() returns -1 if the first version is lower than the second, 0 if they are equal, and 1 if the second is lower."
https://www.php.net/manual/en/function.version-compare.php

Guess the fix in question seems is about configure switches at compile time and not runtime?
https://github.com/php/php-src/pull/11524/files

FYI enterprise Linux distros like Ubuntu, RedHat & co backport patches for supported software.
This is different to always ship the latest (Arch) and requires more work for the aimed stability.
Especially in security audits you proof auditors that it's the base version plus the extra patches.
So if version 8.1.2 is insecure 8.1.2-1ubuntu2.13 is higher as it has i.e. CVE-2023-3247 patched.