Today we discovered that most of our servers that are running Apache2 + libapache2-mod-php had Apache2 running with an older version of PHP, even though libapache2-mod-php(7.4|8.1) was updated.
After investigating, we found that libapache2-mod-php8.1 uses a trigger to reload apache, but that this is not supported in the apache2-maintscript-helper script.
The expected behavior is that after upgrading or reinstalling libapache2-mod-php8.1, Apache2 is restarted. This should be visible by looking at the start time of the apache2 process in the process list.
Although I would be highly surprised if this is actually an issue that has not been reported yet, I could not find any reports mentioning this behavior. Also, there's a security element to this: we expected the package upgrades (we're running unattended updates) to ensure the PHP version we're running is uptodate, but now it turns out we're running old versions of PHP without us knowing.
Today we discovered that most of our servers that are running Apache2 + libapache2-mod-php had Apache2 running with an older version of PHP, even though libapache2- mod-php( 7.4|8.1) was updated. mod-php8. 1 uses a trigger to reload apache, but that this is not supported in the apache2- maintscript- helper script.
After investigating, we found that libapache2-
The expected behavior is that after upgrading or reinstalling libapache2- mod-php8. 1, Apache2 is restarted. This should be visible by looking at the start time of the apache2 process in the process list.
As far as we could find, the problem exists in apache2- maintscript- helper ( https:/ /git.launchpad. net/~agogo147/ ubuntu/ +source/ apache2/ tree/debian/ debhelper/ apache2- maintscript- helper? h=applied/ debian/ bullseye# n221). When the trigger from libapache2- mod-php8. 1 runs, the apache2- maintscript- helper is executed with the following variables:
APACHE2_ MAINTSCRIPT_ NAME=postinst MAINTSCRIPT_ METHOD= triggered MAINTSCRIPT_ ARGUMENT= /etc/php/ 7.4/apache2/ conf.d
APACHE2_
APACHE2_
That means that the apache2_ needs_action function returns 1 (e.g. no action necessary) so the intended reload does not happen.
Output of the trigger of a reinstall of libapache2- mod-php7. 4 with APACHE2_ MAINTSCRIPT_ DEBUG=1 set in envvars:
Processing triggers for libapache2- mod-php7. 4 (7.4.3-4ubuntu2.19) ... MAINTSCRIPT_ DEFER= triggers- awaited| triggers- pending MAINTSCRIPT_ NAME=postinst MAINTSCRIPT_ PACKAGE= libapache2- mod-php7. 4 mod-php7. 4 ] MAINTSCRIPT_ METHOD= triggered MAINTSCRIPT_ ARGUMENT= /etc/php/ 7.4/apache2/ conf.d 7.4/apache2/ conf.d = /etc/php/ 7.4/apache2/ conf.d ] apache2/ apache2- maintscript- helper ] apache2/ apache2- maintscript- helper needs_action
+ APACHE2_
+ + egrep -q installed|
dpkg-query -f ${Status} -W apache2
+ [ -z triggered ]
+ APACHE2_
+ [ postinst ]
+ APACHE2_
+ [ -z libapache2-
+ [ -z ]
+ APACHE2_
+ [ -z ]
+ APACHE2_
+ [ triggered = triggered ]
+ [ /etc/php/
+ [ -e /usr/share/
+ . /usr/share/
+ [ -n 1 ]
+ return
+ apache2_reload restart
+ apache2_
+ [ triggered = configure ]
+ return 1
+ return 0
+ exit 0
Although I would be highly surprised if this is actually an issue that has not been reported yet, I could not find any reports mentioning this behavior. Also, there's a security element to this: we expected the package upgrades (we're running unattended updates) to ensure the PHP version we're running is uptodate, but now it turns out we're running old versions of PHP without us knowing.
ProblemType: Bug mod-php8. 1 8.1.2-1ubuntu2.14 ature: Ubuntu 5.19.0- 43.44~22. 04.1-generic 5.19.17 esult: pass
DistroRelease: Ubuntu 22.04
Package: libapache2-
ProcVersionSign
Uname: Linux 5.19.0-43-generic x86_64
ApportVersion: 2.20.11-0ubuntu82.5
Architecture: amd64
CasperMD5CheckR
CurrentDesktop: GNOME
Date: Tue Oct 10 11:53:51 2023
InstallationDate: Installed on 2023-05-01 (161 days ago)
InstallationMedia: Ubuntu 22.04.2 LTS "Jammy Jellyfish" - Release amd64 (20230223)
SourcePackage: php8.1
UpgradeStatus: No upgrade log present (probably fresh install)