I just updated virtualmin and got a new ajax option to switch mod_php off but after that I can not restart the apache any more
systemctl status httpd.service
host.xxx systemd[1]: Starting The Apache HTTP Server...
host.xxx httpd[2909]: AH00526: Syntax error on line 567 of /etc/httpd/conf/httpd.conf:
host.xxx httpd[2909]: Invalid command 'php_value', perhaps misspelled or defined by a module not included in the server configuration
host.xxx systemd[1]: httpd.service: main process exited, code=exited, status=1/FAILURE
host.xxx systemd[1]: Failed to start The Apache HTTP Server.
host.xxx systemd[1]: Unit httpd.service entered failed state.
host.xxx systemd[1]: httpd.service failed.
At some point you installed, and then uninstalled (or disabled) mod_php. You should not have installed mod_php, but it’s good that you have uninstalled it (or disabled it, in which case you should go ahead and uninstall it, too).
Then remove those php_value directives. They are mod_php directives. It may be that doing a Re-check Configuration and then Validate Virtual Servers in Virtualmin will fix this problem, but I’m not sure. You may need to remove them from the config file yourself.
We’re looking into why the directives weren’t automatically removed when you used the disable feature, as I think they should have been. We’ll fix it in the future, anyway.
This is a problem I see very often, especially on old Debian 9 and/or when migrating sites from Debian 9 to newer distros … even if I nerver installed (nore used) mod_php. I usually solve it like this:
find /etc/apache2/sites-available -name "*.conf" -type f -exec sed -i '/^php_admin_value/d' {} ";"
find /etc/apache2/sites-available -name "*.conf" -type f -exec sed -i '/^php_value/d' {} ";"
/etc/init.d/apache2 restart
Thank you @Ilia … but is it though? I just made the Virtualmin update on a Debian 9 server and I ran into the exact same issue: it appears that some “php_admin_value” and “php_value” lines weren’t properly cleaned preventing Apache from restarting correctly.
That patch is not yet in the Virtualmin virtual-server module package in the repos. It was only patched four hours ago (while I was asleep). It will be in the next Virtualmin release. To test whether it works before then, you’d need to apply that patch manually.
This may have been fixed already, but I thought I’d mention it.
CentOS 7.9
Webmin 1.991
Virtualmin 7.0 Pro
Today I noticed that both Webalizer and Awstats stopped reporting traffic some time during May 8. Because both of them stopped, I figured Apache was at fault somehow and attempted to restart it. It wouldn’t restart. The reason was all that mod_php shit that shouldn’t have been in /etc/httpd/conf/httpd.conf .
I mass-commented it out, Apache started, and the stats programs started reporting again (but didn’t fill in the missing days).
The strange thing is that I’ve never had mod_php installed either before or after the Virtualmin upgrade. Also, this occurred a week after the Virtualmin upgrade, so I figure it has nothing to do with it; but nothing related to Apache happened on the 8th of May that can explain it, either.
In any case, it’s working now, so I’m not looking for the cure. I’m just puzzled as to the cause.
Try to remember what changes did you do recently (perhaps with help of Webmin Action Log module) to the system, like changing PHP execution mode or anything else?
Nothing other than installing a couple of ImageMagick updates, and renewing a few Let’s Encrypt SSL certs (they haven’t updated automatically for about a year, so I just update them manually). Nothing else was changed.
The stats problem began some time early on May 8th New York time. I didn’t even log in on May 8th, so nothing happened that day at all. (I have the updates set to manual.)
I probably should mention that Apache was serving pages just fine the whole time, include database-dependent PHP pages. It just stopped logging on the 8th; and then it wouldn’t restart earlier today because of all the stray mod_php entries.
I do use some remi-safe PHP versions, but they haven’t updated in a long time.
I didn’t change the standard config for a wordpress install from a year or so ago, been running fine through many updates. Few other virtual machines doing not much.
This latest update offered removal of mod_php and after reboot apache stopped responding. Yes maybe mod_php shouldn’t be used, but the removal broke things without checking. I reenabled with a2enmod mod_php7.4 and restarted apache and all resolved. Guess I’ll pick No to everything virtualmin suggests now or wait longer to install updates (both stupid ideas). Not you’re fault the wordpress config is crap, but disabling modules when they are used in config is a bit heavy handed, maybe the advice from @Nico94 could be offered to the user when disabling mod_php to cover yourselves or much more thorough testing?
