Apache Update crashes web server - Failed to start service :

After installation of the new Apache2 update (as recommended in the Virtualmin control area), the Apache web server will not come back online. Instead, it gives me an error:

"Failed to start service : Starting web server: apache2Syntax error on line 51 of /etc/apache2/sites-enabled/bamajr.com.conf: Invalid command 'php_value', perhaps misspelled or defined by a module not included in the server configuration failed!"

I can still log into Virtualmin/Webmin/Usermin, but none of the hosted websites are working!

Status: 
Active

Comments

Howdy -- yeah, that seems to be a problem that occurs in some circumstances during Debian updates.

The error you're seeing is because php_value is a mod_php directive, but it doesn't sound like mod_php is being loaded.

I've seen folks fix this quick by installing mod_php, but you might also just consider commenting those lines out and restarting Apache.

I don't see anything called "mod_php" as an option to install for debian.

Nothing even similar shows up under "apt-cache search mod_php"

Nothing even similar shows up under "apt-cache search mod"

Nothing even similar shows up under "apt-cache search php"

However, I would just as soon install it as comment out the lines of code!

...and, in what area would I comment out the lines of code anyway?

The error shows up in:

/etc/apache2/sites-enabled/SITE-NAME

for every site hosted on the server.

...also, why all of a sudden is this happening, after an "update" no less? I never had this problem on the server before with Apache2. The update has rendered my server useless, until this is fixed!

The line of code that is throughing everything off is:

php_value memory_limit 32M

However, this occurs in every server instance on the virtualmin server!

There is no way this is something that has to be done manually on each virtual server, is there? There is a lot of them and each file would have to be edited manually.

There has to be something that was overlooked when preparing the upgrade for virtualmin!

Add'l Info.

the php_value memory_limit 32M line shows up in all the /etc/apache2/sites-enabled/SITE-NAME.com.conf but also shows up in all the existing /etc/apache2/sites-available/SITE-NAME.com.conf

...but it is not included at all in the /etc/apache2/sites-available/DEFAULT file!

Isn't the DEFAULT file used as a template for creating each of the others?

Add'l Info.

I deleted the line "php_value memory_limit 32M" from 1 virtual site at a time, and tried to restart Apache2 each time.

Some of the instances of "php_value memory_limit 32M" appeared twice in one /etc/apache2/sites-available/SITE-NAME.com.conf file. Other .conf files didn't have a single instance of the "php_value memory_limit 32M" file!

If this was something that was done by Apache, wouldn't this happen across the board?

I've also seen this when Apache's mod_php gets disabled - you can turn it back on at Webmin -> Servers -> Apache Webserver -> Configure Apache Modules.

There is no mod_php listed at: Webmin -> Servers -> Apache Webserver -> Configure Apache Modules.

Neither can I find a mod_php option to install!

Also, make sure you have mod_php installed. The command to run is :

apt-get install libapache2-mod-php5

Note that the last-but-one fairly big Apache upgrade for Debian Lenny didn't just disable but completely removed mod_php on my system, for some bizarre reason presumably known only to the Debian gods.

Thanks for the file name Jamie... but I haven't installed it yet!

I'm not quite buying the whole, "This only happens on Debian" answer. Though, I have read quite a bit about it.

Was libapache2-mod-php5 installed prior to this last Apache2 update?

If it was, why doesn't the Virtualmin Package Updates section find it?

How does it get deleted when installing an update to Apache2?

Also, I went through each site, 1 virtual site at a time. This was an attempt to locate and delete the line "php_value memory_limit 32M" from the virtual site. Why did some of the instances of "php_value memory_limit 32M" appear only once in a couple servers, twice in a couple servers and not at all in a few servers? Every site has a /etc/apache2/sites-available/SITE-NAME.com.conf file, so why wasn't every site affected the same?

Yes, libapache2-mod-php5 should have been installed from the start.

The reason this only effects some domains is that Virtualmin only adds those php_value lines when it installs a script that needs more than the default amount of memory given by PHP, such as SugarCRM.

Yes Jamie, I understand that. However the only scripts installed, right now and at the time of the issue, was WordPress (Not MU version!)

So you would have thought that if if it adds those lines of code when it installs a script needing more than the default amount of memory, it would have installed on all the virtual servers which are running WordPress. However, it did not. Some Virtual Server instances running the WordPress script had the instance of this code twice and two Virtual Server instances running the WordPress script didn't have any instance of this code. While a couple Virtual Server instances not running any scripts, had a single instance of this code.

It didn't seem to be related to the instance of installed scripts!

Do you have any scripts installed other than Wordpress? It's installer doesn't actual set a 32M memory limit at all .. however, those for vTigerCRM and PiWik do.

Ok, So I"m confused... I got this same issue again after the last set of Apache updates, a few days ago. Apache2 fails to start, but the issue only existed on two of the virtual servers. Both had WordPress installed, yet other virtual servers with WordPress installed did not have this problem.

Again, I went through each site, 1 virtual site at a time, searching for the line "php_value memory_limit 32M" to delete it. Once deleted, Apache starts up just fine!

The real issue is a Debian bug - Apache upgrades disable mod_php5, which cause directives in the Apache config like php_value to become invalid.

If you really aren't even using mod_php at all to run PHP scripts, you can just disable mod_php5 permanently. Go to Webmin -> Servers -> Apache Webserver -> Configure Apache Modules, make sure php5 is un-checked, then click the Enable Selected Modules button.

Don't you need PHP5 to be selected if you are using PHP5 for things like phpBB or WordPress?

Joe's picture
Submitted by Joe on Fri, 07/02/2010 - 20:45 Pro Licensee

mod_php5 is not the only way to run PHP applications. The default in Virtualmin (and preferable in a shared hosting environment) is to run them under mod_fcgid with suexec. mod_php is less secure, and usually results in more memory usage and slower performance on high load sites (not always and not for all apps and workloads, but enough of the time that it's the obvious choice unless you know some reason to use something else).