Tumbleweed update to 20221216 breaks Apache2 installation

Following the application of the updates that brought a system up to 220221216 Tumbleweed, the Apache2 web server will not start. There is a complaint about PHP needing to recompiled (which has never been necessary before).

Systemctl status returns:

systemctl status apache2.service

× apache2.service - The Apache Webserver
Loaded: loaded (/usr/lib/systemd/system/apache2.service; enabled; preset: disabled)
Active: failed (Result: exit-code) since Sun 2022-12-18 22:51:22 CST; 1min 9s ago
Process: 4656 ExecStart=/usr/sbin/start_apache2 -DSYSTEMD -DFOREGROUND -k start (code=exited, status=1/FAILURE)
Main PID: 4656 (code=exited, status=1/FAILURE)
CPU: 63ms

Dec 18 22:51:22 klaatu systemd[1]: Starting The Apache Webserver…
Dec 18 22:51:22 klaatu systemd[1]: apache2.service: Main process exited, code=exited, status=1/FAILURE
Dec 18 22:51:22 klaatu start_apache2[4656]: [Sun Dec 18 22:51:22.498786 2022] [php:crit] [pid 4656:tid 140223914719296] Apache is running a threaded MPM, but your PHP Module is not compiled to be threadsafe. You need to recompile PHP.
Dec 18 22:51:22 klaatu start_apache2[4656]: AH00013: Pre-configuration failed
Dec 18 22:51:22 klaatu systemd[1]: apache2.service: Failed with result ‘exit-code’.
Dec 18 22:51:22 klaatu systemd[1]: Failed to start The Apache Webserver.

Why would the list of updates I received regarding updates on 0600 on 12/16 not mention anything about PHP 7 or 8, at all, but when I applied the available updates 30 hours later, I see error messages in the log:

( 65/461) Removing apache2-mod_php7-7.4.33-2.1.x86_64 […
error: %preun(apache2-mod_php7-7.4.33-2.1.x86_64) scriptlet failed, exit status 1
error: apache2-mod_php7-7.4.33-2.1.x86_64: erase failed
.error]
Removal of (73079)apache2-mod_php7-7.4.33-2.1.x86_64(@System) failed:
Error: Subprocess failed. Error: RPM failed: Command exited with status 1.
Abort, retry, ignore? [a/r/i] (a): ( 65/461) Removing apache2-mod_php7-7.4.33-2.1.x86_64 […
error: %preun(apache2-mod_php7-7.4.33-2.1.x86_64) scriptlet failed, exit status 1
error: apache2-mod_php7-7.4.33-2.1.x86_64: erase failed
.error]
Removal of (73079)apache2-mod_php7-7.4.33-2.1.x86_64(@System) failed:
Error: Subprocess failed. Error: RPM failed: Command exited with status 1.
Abort, retry, ignore? [a/r/i] (a): ( 66/461) Removing php7-7.4.33-2.2.x86_64 […done]

There were other PHP7-related removals that seem to have completed successfully:

Checking for file conflicts: […done]
( 1/461) Removing php7-ctype-7.4.33-2.2.x86_64 […done]
( 2/461) Removing php7-iconv-7.4.33-2.2.x86_64 […done]
( 3/461) Removing php7-openssl-7.4.33-2.2.x86_64 […done]
( 4/461) Removing php7-sqlite-7.4.33-2.2.x86_64 […done]
( 5/461) Removing php7-tokenizer-7.4.33-2.2.x86_64 […done]
( 6/461) Removing php7-xmlreader-7.4.33-2.2.x86_64 […done]
( 7/461) Removing php7-xmlwriter-7.4.33-2.2.x86_64 […done]
( 8/461) Removing php7-pdo-7.4.33-2.2.x86_64 […done]
( 9/461) Removing php7-dom-7.4.33-2.2.x86_64 […done]

Since the removes were done before the scriptlet failure messages appeared in the log file, is it reasonable to think that those “Removing php7-xxx” messages should have included a step to remove “apache_mod_php7”

What options do I have to fix this? The Apache server is down for the count until there’s a fix? Do I manually yank the “apache2_mod_php7” module out of the system and try to reinstall/refresh from the repository?

The hell of it is that I’m not even using PHP in conjunction with the any of the web sites that were running on the host.

Looking for suggestions…

This is quite murky talk. I always dup Tumbleweed and never encountered any issues with Apache: The command line is by far the easiest way to update Tumbleweed

Does it help? Apache is running a threaded MPM, but your PHP Module is not compiled to be threadsafe. You need to recompile PHP. AH00013: Pre-configuration failed - Stack Overflow

Not particularly.

Apache and all of the associated packages have been getting installed via either YaST and updates downloaded and applied using zypper. I have never, ever, needed do download sources and recompile a package following an update foul-up. If I were running a system with self-compiled packages, I can see where the error message makes sense but, since that is not the case, the message is not helpful.

Read the rest of my post about the apache_mod_php7 removal failure. Is THAT the source of the problem that’s preventing Apache2 from starting? Was a removal of apache_mod_php7 not done during the early stages of the updates? Because my eyes tell me: No.

The following 14 packages are going to be REMOVED:
apache2-mod_php7 libglslang11_12 libopeniscsiusr0_2_0 php7 php7-ctype php7-dom php7-iconv php7-json php7-openssl php7-pdo php7-sqlite php7-tokenizer php7-xmlreader php7-xmlwriter

Checking for file conflicts: […done]
( 1/461) Removing php7-ctype-7.4.33-2.2.x86_64 […done]
( 2/461) Removing php7-iconv-7.4.33-2.2.x86_64 […done]
( 3/461) Removing php7-openssl-7.4.33-2.2.x86_64 […done]
( 4/461) Removing php7-sqlite-7.4.33-2.2.x86_64 […done]
( 5/461) Removing php7-tokenizer-7.4.33-2.2.x86_64 […done]
( 6/461) Removing php7-xmlreader-7.4.33-2.2.x86_64 […done]
( 7/461) Removing php7-xmlwriter-7.4.33-2.2.x86_64 […done]
( 8/461) Removing php7-pdo-7.4.33-2.2.x86_64 […done]
( 9/461) Removing php7-dom-7.4.33-2.2.x86_64 […done]
( 10/461) Installing: perlref-5.004.1-8.30.noarch […done]
( 11/461) Installing: PackageKit-branding-openSUSE-> 42.1-2.45.noarch […done]

( 64/461) Installing: libpcre2-8-0-10.42-1.1.x86_64 […done]
> ( 65/461) Removing apache2-mod_php7-7.4.33-2.1.x86_64 […
> error: %preun(apache2-mod_php7-7.4.33-2.1.x86_64) scriptlet failed, exit status 1
> error: apache2-mod_php7-7.4.33-2.1.x86_64: erase failed
> .error]
> Removal of (73079)apache2-mod_php7-7.4.33-2.1.x86_64(@System) failed:
> Error: Subprocess failed. Error: RPM failed: Command exited with status 1.
> Abort, retry, ignore? [a/r/i] (a): ( 65/461) Removing apache2-mod_php7-7.4.33-2.1.x86_64 […
> error: %preun(apache2-mod_php7-7.4.33-2.1.x86_64) scriptlet failed, exit status 1
> error: apache2-mod_php7-7.4.33-2.1.x86_64: erase failed
> .error]
> Removal of (73079)apache2-mod_php7-7.4.33-2.1.x86_64(@System) failed:
> Error: Subprocess failed. Error: RPM failed: Command exited with status 1.
> Abort, retry, ignore? [a/r/i] (a): ( 66/461) Removing php7-7.4.33-2.2.x86_64 […done]

Because of the “scriptlet” error, the removal of apache2-mod_php7 sure appears to have NOT taken place.

Is manually removing that package going to suffice in eliminating the mod_php7 problem with Apache2 startup? Or is that liable to create yet another problem?

TIA…

I use a shell script that runs zypper to first download the updates followed by another invocation of zypper to apply them. I get a nice log file emailed to me when the process is complete.

Hello,

This error is probably because MPM threaded isn’t more included in tumbleweed.
MPM threaded is not recommended by apache2 see:
https://www.php.net/manual/en/faq.installation.php#faq.installation.apache2

Regards
Philippe

I have no idea what your script is doing. For some reliable upgrading see The command line is by far the easiest way to update Tumbleweed

Upgrading resulted in the following:

erlangen:~ # zypper se -is apache
Loading repository data...
Reading installed packages...

S  | Name                   | Type    | Version    | Arch   | Repository
---+------------------------+---------+------------+--------+-----------------------
i  | apache-commons-logging | package | 1.2-11.5   | noarch | Haupt-Repository (OSS)
i+ | apache2                | package | 2.4.54-6.1 | x86_64 | Haupt-Repository (OSS)
i+ | apache2-mod_php8       | package | 8.1.13-2.1 | x86_64 | Haupt-Repository (OSS)
i+ | apache2-prefork        | package | 2.4.54-6.1 | x86_64 | Haupt-Repository (OSS)
i+ | apache2-utils          | package | 2.4.54-6.1 | x86_64 | Haupt-Repository (OSS)
erlangen:~ # 
erlangen:~ # systemctl status apache
● apache2.service - The Apache Webserver
     Loaded: loaded (/usr/lib/systemd/system/apache2.service; enabled; preset: disabled)
     Active: active (running) since Mon 2022-12-19 18:29:52 CET; 4s ago
   Main PID: 19688 (httpd-prefork)
     Status: "Processing requests..."
      Tasks: 6
        CPU: 27ms
     CGroup: /system.slice/apache2.service
             ├─19688 /usr/sbin/httpd-prefork -DSYSCONFIG -DSSL -C "PidFile /run/httpd.pid" -C "Include /etc/apache2/sysconfig.d//loadmodule.conf" -C "Include /etc/apache2/sysconfig.d//global.conf" -f /etc/apache2/httpd.conf -c "Include />
             ├─19704 /usr/sbin/httpd-prefork -DSYSCONFIG -DSSL -C "PidFile /run/httpd.pid" -C "Include /etc/apache2/sysconfig.d//loadmodule.conf" -C "Include /etc/apache2/sysconfig.d//global.conf" -f /etc/apache2/httpd.conf -c "Include />
             ├─19705 /usr/sbin/httpd-prefork -DSYSCONFIG -DSSL -C "PidFile /run/httpd.pid" -C "Include /etc/apache2/sysconfig.d//loadmodule.conf" -C "Include /etc/apache2/sysconfig.d//global.conf" -f /etc/apache2/httpd.conf -c "Include />
             ├─19706 /usr/sbin/httpd-prefork -DSYSCONFIG -DSSL -C "PidFile /run/httpd.pid" -C "Include /etc/apache2/sysconfig.d//loadmodule.conf" -C "Include /etc/apache2/sysconfig.d//global.conf" -f /etc/apache2/httpd.conf -c "Include />
             ├─19707 /usr/sbin/httpd-prefork -DSYSCONFIG -DSSL -C "PidFile /run/httpd.pid" -C "Include /etc/apache2/sysconfig.d//loadmodule.conf" -C "Include /etc/apache2/sysconfig.d//global.conf" -f /etc/apache2/httpd.conf -c "Include />
             └─19708 /usr/sbin/httpd-prefork -DSYSCONFIG -DSSL -C "PidFile /run/httpd.pid" -C "Include /etc/apache2/sysconfig.d//loadmodule.conf" -C "Include /etc/apache2/sysconfig.d//global.conf" -f /etc/apache2/httpd.conf -c "Include />

Dec 19 18:29:52 erlangen systemd[1]: Starting The Apache Webserver...
Dec 19 18:29:52 erlangen systemd[1]: Started The Apache Webserver.
erlangen:~ # 

Of course… the wrapper script around zypper that I’ve been using successfully for several years caused the apache_mod_php7 uninstall process scriptlet to fail.

I had the same problem with apache2-mod_php7-7.4.33-2.1.x86_64 yesterday. I tried it again today and it failed again.

My update process has not changed for 2 years. I shutdown all desktop applications, but do not log out of my desktop session. I switch to a console with ctrl-alt-F1. I log in as root and run the following two commands, then reboot.

zypper ref
zypper dup --no-recommends

I don’t use Apache & have made no changes to my system since a successful update a week ago. I don’t think the problem is caused by anything I’ve done (or not done), though that’s always a possibility.

Still looking for a fix.

Perhaps re-post the problem in the Install/Boot/Login category? It may get more attention there.