I'm not sure for how long we will support apache-mod_php. It is recommended to use php-fpm via cgi/proxy request instead.

CC: (none) => mageia

No, a postin is not needed.  This is already handled via file triggers.

Status: NEW => RESOLVED
Resolution: (none) => INVALID

Denying the problem won't make it disappear. The filetrigger installed by Apache package tries to be smart and just reload the server if there is no new configuration file, which is fine for minor configuration change, but probably not enough for a full embedded interpreter version change, as we now push new PHP version instead of backporting fixes.

Transitioning from mod_php to php-fpm is indead an option, but as long as mod_php is included in the distribution, this kind of issue should be fixed.

Resolution: INVALID => (none)
Status: RESOLVED => REOPENED

we don't push "new versions". These are bugfixes, but maintained by php developers. Nevertheless, I agree, we have to restart apache process, if mod-apache is installed and updated.
In case extensions get updated, you still have to restart apache by yourself.

Do we have a macro to check if apache is running and then restart it?

(In reply to Marc Krämer from comment #4)
> we don't push "new versions". These are bugfixes, but maintained by php
> developers. Nevertheless, I agree, we have to restart apache process, if
> mod-apache is installed and updated.

I don't see in the changelog that this got fixed, so assuming this report is still valid for php-8.1.7-4.mga9 and assigning to the php stack maintainers.

> In case extensions get updated, you still have to restart apache by yourself.
> 
> Do we have a macro to check if apache is running and then restart it?

Assignee: bugsquad => php
CC: (none) => marja11
Source RPM: php => php-8.1.7-4.mga9

(In reply to Guillaume Rousse from comment #3)
> Denying the problem won't make it disappear. The filetrigger installed by
> Apache package tries to be smart and just reload the server if there is no
> new configuration file, which is fine for minor configuration change, but
> probably not enough for a full embedded interpreter version change, as we
> now push new PHP version instead of backporting fixes.
> 
> Transitioning from mod_php to php-fpm is indead an option, but as long as
> mod_php is included in the distribution, this kind of issue should be fixed.

No, the file trigger triggers on Apache modules.  If it's not triggering, then we need to figure out why.  Adding scriplets is not a correct fix.

CC: (none) => luigiwalser

on update of apache-mod_php, only /usr/lib64/httpd/modules/ is changed by a new file. So file triggers must monitor this directory for changes.

Unless someone broke something, it should be doing that.  I fixed this 10 years ago, but the file triggers model has been switched from Mandrake's original implementation to the new upstream rpm implementation since then.

I did not test it - but is it possible the reload is "too early", so the new file is placed there, but not all modules got updated and therefore mod-php does not work?
During update modules are updated and in between php itself. If the reload occurs at this point php will not work.
For the latest release the dependancies should work better than before, but not all (external) modules have the explicit dependancy set.

Here is the systemd unit file corresponding to the reload command:
ExecReload=/usr/sbin/httpd $OPTIONS -k graceful

According to the official documentation, this only allows to re-read configuration files and reopen log files:
https://httpd.apache.org/docs/2.4/stopping.html

It seems quite clear this is not enough to reload an apache module, such as mod_php, or any other, whose binary file would have changed on disk. The current filetrigger should also check /etc/httpd/modules/ path, and force a restart if anything there is updated.

right. I assume we should move this report to apache maintainer, since there is nothing to be done me.
AFAIK nobody is responsible for apache (which I think is bad for such a big component).

@David: if you have implemented this feature, maybe you can update/change the trigger?

The file trigger wouldn't be using ExecReload from the systemd service file, and yes, it should already be calling for a restart on changed Apache modules.

Sorry for the delay, just getting back to this now.  So the conversion to new triggers was done here:
http://svnweb.mageia.org/packages/cauldron/apache/current/SPECS/apache.spec?r1=873160&r2=873159&pathrev=873160

It looks like a faithful translation.  One interesting thing, it calls "systemctl reload-or-try-restart" but that command is not listed in the man page.  It looks like it should be "systemctl try-reload-or-restart" instead.

I've made that change in Cauldron.  I guess we'll see on the next PHP update how that fares.

@David: file triggers do NOT monitor /usr/lib64/httpd/modules/
and if we update php, the file in
/etc/httpd/conf/modules.d/
is not changed! Only the binary in /usr/lib64/httpd/modules/ is replaced by a new version and this requires an restart of apache.

and - the file is not NEW or DELETED, it is just replaced by a newer version - so 
@new_files and @old_files will both be empty.

Marc, it's fine, it will hit the else clause in the trigger.

true, overread the else, but the binary location is missing:
 %transfiletriggerin -p /usr/bin/perl --  /etc/httpd/conf/modules.d/ /etc/httpd/conf/modules/sites.d/ /etc/httpd/conf/modules/conf.d/ /etc/httpd/conf/modules/webapps.d/

Yeah, but anything with a module should have a module configuration file, so it'll catch it.

but if it does not change, does the trigger really fire???

Yes.

(In reply to David Walser from comment #13)
> Sorry for the delay, just getting back to this now.  So the conversion to
> new triggers was done here:
> http://svnweb.mageia.org/packages/cauldron/apache/current/SPECS/apache.
> spec?r1=873160&r2=873159&pathrev=873160
> 
> It looks like a faithful translation.  One interesting thing, it calls
> "systemctl reload-or-try-restart" but that command is not listed in the man
> page.  It looks like it should be "systemctl try-reload-or-restart" instead.
> 
> I've made that change in Cauldron.  I guess we'll see on the next PHP update
> how that fares.

Change now also made in update candidate for Mageia 8.

See https://bugs.mageia.org/show_bug.cgi?id=29620#c12

There's a PHP update in updates_testing, so this can be tested now.  See:
https://bugs.mageia.org/show_bug.cgi?id=29620#c25

As per https://bugs.mageia.org/show_bug.cgi?id=29620#c27 appears to be working
as far as I can tell.

CC: (none) => davidwhodgins

Fixed in:
https://advisories.mageia.org/MGAA-2022-0119.html

Thanks for the report, and sorry for not believing you at first!

Status: REOPENED => RESOLVED
Resolution: (none) => FIXED