Upgrade of libapache2-mod-php8.1 does not reload apache2

[Roel van Meer]

[ Impact ]

The apache2-maintscript-helper shipped with apache2 to be used by its reversed dependencies to interact with the provided services do not support package triggers.

Package triggers may be specially useful in cases where software plugins or extensions are changed. This is the case of PHP: it relies on such triggers to request apache2 restarts in the libapache2-mod-phpX.Y postinst whenever PHP or one of its extensions is updated.

Since there is no support for triggers in apache2-maintscript-helper, apache2 ends up not being restarted and users may end up with outdated PHP versions running within their web server.

[ Test Plan ]

A test script is available at https://bugs.launchpad.net/debian/+source/apache2/+bug/2038912/comments/5.

First, verify the issue by running `UBUNTU_SERIES=jammy ./reproducer.sh`. The script will print the version of PHP (fetched from an HTTP request to apache2)
- before an update,
- after an update, and
- after a restart.
Without the fix, only the version after the restart should be different.

Then, run it with `TEST_FIX=1 UBUNTU_SERIES=jammy ./reproducer.sh`.
Now, the only different version should be the one before the update (meaning that updating the package will ensure the new version is running within the web server right after the update). Make sure to adjust UBUNTU_SERIES accordingly.

Also, the script was written to use the proposed fix from a PPA, is should be adjusted to fetch it from the -proposed pocket once the fix is accepted.

[ Where problems could occur ]

There may be situations we did not account for where supporting "postinst triggered" in the helper script is not a supported use case. This should most likely be analyzed in a case-by-case fashion.

FWIW, AFAICT, PHP is the only package using apache2's maintscript-helper to restart the service through a trigger (based on queries in Debian codesearch).

[ Other Info ]

Since we are touching an apache2 helper used by several other packages, we wanted to get input from Debian before landing this SRU to ensure this is something we will merge upstream at some point. Since we still did not get a reply, let's move forward here to ensure we get a fix in noble (this is an important bug if users are led to believe apache2 is being restarted when they update PHP).

[ Original Message ]

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.

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
APACHE2_MAINTSCRIPT_METHOD=triggered
APACHE2_MAINTSCRIPT_ARGUMENT=/etc/php/7.4/apache2/conf.d

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) ...
+ APACHE2_MAINTSCRIPT_DEFER=
+ + egrep -q installed|triggers-awaited|triggers-pending
dpkg-query -f ${Status} -W apache2
+ [ -z triggered ]
+ APACHE2_MAINTSCRIPT_NAME=postinst
+ [ postinst ]
+ APACHE2_MAINTSCRIPT_PACKAGE=libapache2-mod-php7.4
+ [ -z libapache2-mod-php7.4 ]
+ [ -z ]
+ APACHE2_MAINTSCRIPT_METHOD=triggered
+ [ -z ]
+ APACHE2_MAINTSCRIPT_ARGUMENT=/etc/php/7.4/apache2/conf.d
+ [ triggered = triggered ]
+ [ /etc/php/7.4/apache2/conf.d = /etc/php/7.4/apache2/conf.d ]
+ [ -e /usr/share/apache2/apache2-maintscript-helper ]
+ . /usr/share/apache2/apache2-maintscript-helper
+ [ -n 1 ]
+ return
+ apache2_reload restart
+ apache2_needs_action
+ [ 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
DistroRelease: Ubuntu 22.04
Package: libapache2-mod-php8.1 8.1.2-1ubuntu2.14
ProcVersionSignature: Ubuntu 5.19.0-43.44~22.04.1-generic 5.19.17
Uname: Linux 5.19.0-43-generic x86_64
ApportVersion: 2.20.11-0ubuntu82.5
Architecture: amd64
CasperMD5CheckResult: pass
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)

[Roel van Meer (rvm-peercode)]

Dear maintainer,

Thanks for taking the time to look at this.
The attached patch to apache2-maintscript-helper fixes the problem. I hope it will be useful.

If there's anything I can do to help or test, please let me know.

Best regards, Roel

[Roel van Meer (rvm-peercode)]

Debian Salsa MR: https://salsa.debian.org/apache-team/apache2/-/merge_requests/40

[Ubuntu Foundations Team Bug Bot (crichton)]

The attachment "Allow trigger to restart apache in apache2-maintscript-helper" seems to be a patch. If it isn't, please remove the "patch" flag from the attachment, remove the "patch" tag, and if you are a member of the ~ubuntu-reviewers, unsubscribe the team.

[This is an automated message performed by a Launchpad user owned by ~brian-murray, for any issues please contact him.]

[Athos Ribeiro (athos-ribeiro)]

Attached is a reproducer.

Running it without defining the TEST_FIX environment variable should reproduce the described bug.

Running it with a TEST_FIX=1 environment variable defined will use apache2 from a PPA with the proposed fix.

Since for now our PHP packages set the PHP_EXTRA_VERSION, this script should be enough to verify the fix.

[Athos Ribeiro (athos-ribeiro)]

After discussing this within the server team, we decided to let this update sit in noble for a while, so we can understand its impact on users before we keep pushing for the SRUs here.

The reason for that is that most other packages will not restart apache2 (nor other services) after an upgrade (we do understand the benefits of the restart in case of security updates though).

FWIW, needrestart does warn/query for the restart need for the upgrade path being addressed here.

In the meanwhile, I will ping Debian again so we can be sure we are in the same page regarding the regression potential for this change.

[Launchpad Janitor (janitor)]

This bug was fixed in the package apache2 - 2.4.58-1ubuntu6

---------------
apache2 (2.4.58-1ubuntu6) noble; urgency=medium

  * d/debhelper/apache2-maintscript-helper: Allow execution when called from a
    postinst script through a trigger (i.e., postinst triggered).
    Thanks to Roel van Meer. (LP: #2038912) (Closes: #1060450)

 -- Athos Ribeiro <email address hidden> Mon, 18 Mar 2024 09:35:36 -0300

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Brian Murray (brian-murray)]

Ubuntu 23.10 (Mantic Minotaur) has reached end of life, so this bug will not be fixed for that specific release.

[Athos Ribeiro (athos-ribeiro)]

There is an initial review in https://salsa.debian.org/apache-team/apache2/-/merge_requests/40 which seem positive rewarding the change. Since this is already applied in our development release, let's wait a bit more to see if it lands in Debian as is before proceeding with SRUs.