Php cli stopped working after system update

Virtualmin
1
SYSTEM INFORMATION
OS type and version Ubuntu Linux 22.04.5
Webmin version 2.303
Virtualmin version 7.30.8
Webserver version Apache 2.4.52
Related packages php8.3 php8.4

During the latest system OS update php8.4 (which I had previously uninstalled) was brought back in. Websites were working fine but php cli was not executing the code (php -v showed the correct version: 8.3). I checked all php configurations and all are pointing to 8.3 which is the version I want to use.

After I uninstalled all php8.4 packages then php cli worked again, php fpm8.4 is no longer there but if I go to software versions I see:
PHP versions 7.4.33, 8.3.19, 8.3.19

I restarted all FPM servers but maybe need to restart Apache as well ?

As this may happen again at the next OS update I would like to know if there is a way to keep php8.4 but work with 8.3cli, any pointers/ideas ?

Let me know if you need more info.
Thanks
Roberto

2

Did you run php -v logged in as domain owner or as root?

How exactly did you first install and then uninstall PHP 8.4?

3

I ran php -v as domain owner, the same user that runs the php scrips

php8.4 install was through the “Software Package Updates” page (is php8.4 bundled with the new OS version ?)

php8.4 uninstall was from the “Software Packages” page: searched for all php8.4 packages, selected all and “Uninstall selected packages”

Software versions is now correct: PHP versions 7.4.33, 8.3.19 it probably needed some refresh

4

Please consider reading this manual before installing additional PHP versions:

5

I am aware but:

  • I did not install php8.4 , it came as part of an OS update (I could not select/deselect it)
  • I did all the checks/verifications
  • I have installed other php versions on Virtualmin before following the manual instructions, but this was not a manual installation, sorry to repeat but it was done automagically as part of the OS update, I found out it installed php8.4 only at the end of the update
6

I’m skeptical that an Ubuntu 22 forces a newer PHP? I know it is an LTS version but still… If so, one more reason to dislike Ubuntu for me.

I always check what is installed during an update. The Webmin interface lets you choose what packages are installed. Something not right here.

Have you tried apt purge?

7

If an update to php8.4 occurred, it was because php8.4 was already installed. Maybe it was installed as a dependency of some other thing you installed at some point, rather than intentionally installed, but updating in Webmin/Virtualmin or directly using apt won’t cause a wholly new package to be installed (except to satisfy dependencies, but that won’t ever happen for php8.4 with system packages), it only updates already installed packages.

There may be one case where it could happen, but it wouldn’t happen with any system packages…only third party would behave like this. And, that would be if you installed a package that previously depended on some other PHP version and then an update depended on a newer PHP version. In that case, a different PHP version might be installed to satisfy that dependency. But, again, that won’t happen with OS packages (OS packages won’t depend on a package like php8.4 in any circumstance, since those come from a third party repo), so you’d have to have installed some third party package that depends on a versions PHP package. I advise caution with third party packages, and keep up with what you’ve installed that way and what they depend on.

So, since the case of an update installing a new package that wasn’t previously installed is unlikely, you should probably check the logs (in /var/lib/apt and /var/lib/dpkg probably) to figure out when and who installed php8.4, so you have an explanation for how you got here, and will know how to avoid it in the future (maybe removing the third-party package that depends on it, if that’s how it happened).

8

@rlattuad what files are in the folder:

/etc/apt/sources.list.d/

My guess is you have a third-party PHP repo, as Ubuntu 22.04 as I understand comes packaged with PHP 8.1 by default, and LTS releases don’t generally upgrade to newer version, but rather patch the version they support for the duration of the release.

If you have a third-party repo misconfigured, it may be tracking the “latest” version of PHP causing 8.4 to be installed and maintained.

9

Not that it means much in this context, but… :wink:

In my VERY limited involvement with PHP, I did notice cli seemed to use the highest version available. I think I was trying to install a forum software package and I had the proper PHP configured for that domain but the ‘crappy?’ installer looked for a fairly narrow PHP version and the script didn’t seem to allow for forward versions.

The point? Should the cli client be looking for the PHP version listed for the site? That didn’t seem to be the case but this is going from memory but seems to jibe with what the OP is saying.

EDI T: In short, are we looking at the wrong problem? One version of PHP shouldn’t break another. All sites have one version as far as I know and should use the same CLI as the site version.

10

Repo configuration or misconfiguration won’t make packages install themselves.

If the package really is named php8.4, then the system package will never be replaced or upgraded into it. php8.4 is a completely different package from php or php8.3 or php8.1.

And, while we’re on the subject, you should never install php or php8.4. You should install the specific packages you need (see our documentation). php or php8.4 is a metapackage on Debian/Ubuntu that will cause mod_php to be installed in most cases, which is a bad thing you never want to happen. see the deps here: Ubuntu – Details of package php8.3 in noble

11

manticoresearch.list
ondrej-ubuntu-php-jammy.list
ubuntu-esm-apps.list
ubuntu-esm-infra.list
virtualmin.list

Manticore was not updated when the problem occurred

12

Checked the logs, let me know if you want the complete files and I will upload, but it seems this bit may give a clue:

Start-Date: 2025-04-07 23:47:46
Commandline: apt-get -y install apache2 apache2-bin apache2-data apache2-suexec-custom apache2-utils linux-generic linux-headers-generic linux-image-generic linux-libc-dev php-cgi php-cli php-common php-fpm php-mbstring php-mysql php-xml
Install: php8.4-mbstring:amd64 (8.4.5-1+ubuntu22.04.1+deb.sury.org+1, automatic), php8.4-xml:amd64 (8.4.5-1+ubuntu22.04.1+deb.sury.org+1, automatic), php8.4-readline:amd64 (8.4.5-1+ubuntu22.04.1+deb.sury.org+1, automatic), linux-modules-extra-5.15.0-136-generic:amd64 (5.15.0-136.147, automatic), linux-headers-5.15.0-136-generic:amd64 (5.15.0-136.147, automatic), linux-headers-5.15.0-136:amd64 (5.15.0-136.147, automatic), php8.4-mysql:amd64 (8.4.5-1+ubuntu22.04.1+deb.sury.org+1, automatic), php8.4-opcache:amd64 (8.4.5-1+ubuntu22.04.1+deb.sury.org+1, automatic), php8.4-common:amd64 (8.4.5-1+ubuntu22.04.1+deb.sury.org+1, automatic), linux-image-5.15.0-136-generic:amd64 (5.15.0-136.147, automatic), linux-modules-5.15.0-136-generic:amd64 (5.15.0-136.147, automatic), php8.4-cgi:amd64 (8.4.5-1+ubuntu22.04.1+deb.sury.org+1, automatic), php8.4-cli:amd64 (8.4.5-1+ubuntu22.04.1+deb.sury.org+1, automatic), php8.4-fpm:amd64 (8.4.5-1+ubuntu22.04.1+deb.sury.org+1, automatic)
Upgrade: linux-headers-generic:amd64 (5.15.0.135.133, 5.15.0.136.134), php-common:amd64 (2:95+ubuntu22.04.1+deb.sury.org+2, 2:96+ubuntu22.04.1+deb.sury.org+1), apache2-suexec-custom:amd64 (2.4.52-1ubuntu4.13, 2.4.52-1ubuntu4.14), linux-generic:amd64 (5.15.0.135.133, 5.15.0.136.134), apache2-data:amd64 (2.4.52-1ubuntu4.13, 2.4.52-1ubuntu4.14), apache2-bin:amd64 (2.4.52-1ubuntu4.13, 2.4.52-1ubuntu4.14), php-mbstring:amd64 (2:8.3+95+ubuntu22.04.1+deb.sury.org+2, 2:8.4+96+ubuntu22.04.1+deb.sury.org+1), php-cgi:amd64 (2:8.3+95+ubuntu22.04.1+deb.sury.org+2, 2:8.4+96+ubuntu22.04.1+deb.sury.org+1), php-cli:amd64 (2:8.3+95+ubuntu22.04.1+deb.sury.org+2, 2:8.4+96+ubuntu22.04.1+deb.sury.org+1), php-fpm:amd64 (2:8.3+95+ubuntu22.04.1+deb.sury.org+2, 2:8.4+96+ubuntu22.04.1+deb.sury.org+1), php-mysql:amd64 (2:8.3+95+ubuntu22.04.1+deb.sury.org+2, 2:8.4+96+ubuntu22.04.1+deb.sury.org+1), linux-image-generic:amd64 (5.15.0.135.133, 5.15.0.136.134), php-xml:amd64 (2:8.3+95+ubuntu22.04.1+deb.sury.org+2, 2:8.4+96+ubuntu22.04.1+deb.sury.org+1), apache2-utils:amd64 (2.4.52-1ubuntu4.13, 2.4.52-1ubuntu4.14), apache2:amd64 (2.4.52-1ubuntu4.13, 2.4.52-1ubuntu4.14), linux-libc-dev:amd64 (5.15.0-135.146, 5.15.0-136.147)
End-Date: 2025-04-07 23:48:24

I may want to point out that the fact that the system installed php8.4 (even if not requested) does not bother me too much, I am more worried by the fact that php_cli stopped working after the update. All users/sites/profiles were set to php8.3 (or in a couple of cases an older php7.4 version), php-v showed it was using the correct version but the only way to get php_cli back running was to remove 8.4. I may try adding php_8.4 using the proper multi-php webmin repo to avoid the same problem in the future

Hope this helps

13

Can you elaborate on this? How exactly did it stop working? Were there any errors when you ran php -v? Did you check the PHP error log for the applications that didn’t work?

Some PHP versions might have certain extensions installed that others don’t. This could result in a situation where an application using PHP 8.4 appears to be malfunctioning when, in fact, it may simply be missing an extension that another PHP version has installed.

14

No errors in the log, no errors from php -v which was giving the correct 8.3 version.
It was just printing out the php code instead of executing it.

15

Which PHP execution mode did you use for the domain on the “PHP Options” page?

16

FPM for all virtual servers

17

Does it help if you change the PHP execution mode to something else, like CGI or FCGI? Does switching back to FPM then solve the problem? Does this issue happen only with PHP 8.4 on your system?

18

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.