Recent apache2 updates killed PHP (no pages served)
Recently I got an update notice for Debian Squeeze apache2. It was:
An update to apache2 from 2.2.16-6+squeeze3 to 2.2.16-6+squeeze4 is available.
An update to apache2-mpm-prefork from 2.2.16-6+squeeze3 to 2.2.16-6+squeeze4 is available.
An update to apache2-utils from 2.2.16-6+squeeze3 to 2.2.16-6+squeeze4 is available.
An update to apache2.2-bin from 2.2.16-6+squeeze3 to 2.2.16-6+squeeze4 is available.
An update to apache2.2-common from 2.2.16-6+squeeze3 to 2.2.16-6+squeeze4 is available.
I waited my customary week to make sure there were no pending problems, then did the upgrade. Promptly, apache2 stopped serving PHP web pages. HTML, fine. Other technologies, fine. PHP, no.
I searched around on google and found one reference to this, and a possible mod_libjk, so I installed that, but still no worky. I'm now dead with no PHP sites working. I have rebooted the node, too.
Anyone have any ideas on what to check to get past this?
Thanks!
bruce
10 Replies
Give "a2enmod php" a shot (I can't remember if debian provides the a2enmod/a2ensite utilities though)
@Obsidian:
Judging by you using prefork, I'm gonna guess you ran PHP via mod_php here.
Give "a2enmod php" a shot (I can't remember if debian provides the a2enmod/a2ensite utilities though)
Okay, good shot, but no dice. I tried "a2enmod php5" and it complained about not finding the .so in the modules directory. I did find a libphp5filter.so, so I changed the .load file to reference it, but I'm getting the same result: no php web pages.
Mind you, I don't have a particularly complex configuration here. It was working fine yesterday, using pretty much out of the box apache2 and php configuration. I can't imagine why this upgrade killed it.
Other ideas?
My php version:
PHP 5.3.3-7+squeeze3 with Suhosin-Patch (cli) (built: Jun 28 2011 13:13:26)
Apache version:
Server version: Apache/2.2.16 (Debian)
Server built: Sep 25 2011 22:18:56
Check the repos for mod_php, it may have been uninstalled by an update. If so, you'll need to reinstall it.
apt-get install --reinstall libapache2-mod-php5
@Obsidian:
No, undo that change. You should not be altering .load files.
Check the repos for mod_php, it may have been uninstalled by an update. If so, you'll need to reinstall it.
Right, so I came to the same conclusion immediately after posting my last. I went out and undid my change, then went to find out why I had php5filter. Turns out it's a debian thing, and it's mutually exclusive with php5.
So (per the comment above) I a2dismod'd php5filter and apt-get installed php5 (it needed php5-cgi, which I installed too).
However! I still don't have working php. I see in mods-enabled that there is a php5 (NOT a modphp…). Should I be seeing a specific "modphp" module enabled? Or is that "php5" equivalent?
Thanks guys, this is helping. Not there yet, but I appreciate the help.
thanks,
bruce
When you say it can't serve php pages what actually happens, do you get a blank page or does it try and download the file or something else?
Anything in the error logs?
@obs:
php5_module is the correct one.
When you say it can't serve php pages what actually happens, do you get a blank page or does it try and download the file or something else?
Anything in the error logs?
It downloads the actual PHP.
I don't see anything obvious in the logs. I've looked a couple of times now, but I'm willing to go look again. Any suggestions on which log files might be more valuable/telling than others?
If so run````
a2enmod php5 && /etc/init.d/apache2 restart
then clear your web browser cache and try again.
@obs:
Does this […] If so run
a2enmod php5 && /etc/init.d/apache2 restartthen clear your web browser cache and try again.
Yeah, so, brilliant.
That all did exist, and I had previously checked it when I was futzing with the .load file. However, it looks like I can blame this on Chrome.
At some point in the discussion above, things started working again. But because I kept retrying the same couple of web sites, they continued to be downloaded. For whatever reason, Chrome thinks that's now the desired behavior. Damn it.
I tried a number of other sites, and all now work. I emptied the cache in Chrome and now the other, previously-failing, sites worked. I hate it when technology tries to out think me.
Anyhow, my thanks for booting my brain in that direction.
THANKS EVERYONE!
bruce
@bbergman:
At some point in the discussion above, things started working again. But because I kept retrying the same couple of web sites, they continued to be downloaded. For whatever reason, Chrome thinks that's now the desired behavior. Damn it.
Fwiw, Chrome was actually just obeying the caching headers that Apache had originally sent previously, and acting according to the HTTP spec.