After some package updates webmin restarted apache and it errored with this.
Forcing reload of web server (apache2)…Syntax error on line 27 of /etc/apache2/sites-enabled/domain.com.conf:
Invalid command ‘php_value’, perhaps misspelled or defined by a module not included in the server configuration
failed!
Line 27 is:
php_value memory_limit 32M
What got updated:
An update to apache2 2.2.3-50vm is available :
An update to openssl 0.9.8c-4etch1 is available :
An update to perl 5.8.8-7etch1 is available :
An update to usermin 1.300 is available :
An update to usermin-virtual-server-theme 4.8 is available :
An update to webmin 1.370 is available :
An update to webmin-security-updates 2.4 is available :
An update to webmin-virtual-server 3.48-3 is available :
An update to webmin-virtual-server-theme 4.8 is available :
An update to webmin-virtualmin-mailman 4.5 is available :
For now i commented it out in a few of the virtual servers, since not all of them had the line. Now apache at least starts up. I did some looking around but didn’t find much and didn’t want to cause any more problems by changing stuff. Using Virutalmin Pro + Debian 4.
You’ve gone from running PHP under mod_php to running it under mod_fcgid or as CGI.
You can safely remove that line from the configuration file. (Though, I’m surprised it remained…if you switched using Virtualmin it should have cleaned up after itself. I’ll have to do some testing on that.)
Also worth noting, any previously installed scripts might have permissions or ownership issues. It’s not really safe for Virtualmin to change them automatically…so, you’ll want to check to be sure the scripts in the converted domain are owned by the domain user and group, and set with 750 or lower permissions (they cannot be group or other writable or suexec will refuse to run them with a 500 error and a message in the suexec_log).
I confirm the same happened to about 6 or so of my sites. Deleted the php value entry and Apache was able to be started. However, on those sites now I get a problem opening a php file (the index).
application/x-httpd-php
Now the browser doesn’t know how to deal with this. I’m just beginning to track this down - but not what I wanted to find at my midnight upgrade.
Now the browser doesn't know how to deal with this.
For some reason it sounds like mod_php has been disabled on your system, where it had been in use before. I can’t think of any updates that we’ve rolled out that would effect this…a virtual-server update could poke at it (it shouldn’t, but I guess it could, if Jamie changed some defaults), but it’s been about a month since we’ve rolled a virtual-server release.
Anyway, the solution is to switch execution modes for the effected virtual servers–select the effected virtual server in the dropdown, and open the "Website Options" page (find it in the Server Configuration menu). Switch from whatever the current mode is to something else, and then switch it back (or take this as an opportunity to switch to mod_fcgid–labeled "FCGId (run as virtual server owner)", as this is the best balance between security and performance for the vast majority of users).
This will resolve any weirdness with regard to Apache recognizing the file type.
It may introduce new permissions problems as mentioned above. chown them user:group of the virtual server administrator user, and set them 750 or lower permissions.
If anybody has any idea what package triggered this change, give me a holler. I can’t say it’s a fluke if more than one person is seeing it. But I also can’t figure out what we’ve rolled out in the past two weeks (or more) that could have possibly changed anything relevant to this error.
Yes I’m on Debian 4. The weird thing is that I thought about making the changes you stated and when I pulled up the Website options, neither option was selected for PHP execution mode. I then selected the FCGId (run as virtual server owner) and this did not help. I even tried to toggle the other option, restarting apache both times.
Still stuck. I’m going to send you credentials for the server again.
I guess I was caching some stuff local - should have went to sleep… Anyhow, after toggling the options and/or playing with resetting the PHP version on all these sites and restarting apache it seemed to repair itself.