I have multiple virtual servers each of which is serving its own installation of WordPress. These have all been working properly for weeks to years.
Today I've been switching servers from Apache mod_php to FCGId if they were not already using FCGId. This has mostly gone relatively smoothly so far, but in a couple of cases, when testing the result of the change by visiting the respective WordPress site, I get the error message "Your PHP installation appears to be missing the MySQL extension which is required by WordPress."
I've looked around and can't see any difference between configurations - can you please help me understand what's gone wrong and how to fix it?
Status:
Active
Comments
Submitted by andreychek on Wed, 08/24/2016 - 09:44 Comment #1
Howdy -- those two modes do use different config files... mod_php uses a php.ini file from /etc/, where FCGID uses the one in $HOME/etc/php.ini.
One place to start though, what is the output of this command:
ls /etc/php5/conf.d/Based on your reply, I thought to compare a [working-site]/etc/php.ini and a [non-working-site]/etc/php.ini , but couldn't spot any MySQL-specific differences :(
Here's the output you requested:
ls -Al /etc/php5/conf.d/total 48
-rw-r--r-- 1 root root 17 Apr 3 2010 apc.ini
-rw-r--r-- 1 root root 54 Jun 10 2012 curl.ini
-rw-r--r-- 1 root root 50 Jun 10 2012 gd.ini
-rw-r--r-- 1 root root 54 Jun 10 2012 imap.ini
-rw-r--r-- 1 root root 54 Jun 10 2012 ldap.ini
-rw-r--r-- 1 root root 58 May 8 2012 mcrypt.ini
-rw-r--r-- 1 root root 57 May 8 2012 mysqli.ini
-rw-r--r-- 1 root root 56 May 8 2012 mysql.ini
-rw-r--r-- 1 root root 52 May 8 2012 pdo.ini
-rw-r--r-- 1 root root 60 May 8 2012 pdo_mysql.ini
-rw-r--r-- 1 root root 3399 Aug 19 2010 suhosin.ini
-rw-r--r-- 1 root root 52 Mar 4 2013 xsl.ini
Submitted by andreychek on Wed, 08/24/2016 - 11:51 Comment #3
What are the contents of the mysql.ini and mysqli.ini files in that directory?
$ cat mysql.ini
; configuration for php MySQL module
extension=mysql.so
$ cat mysqli.ini
; configuration for php MySQL module
extension=mysqli.so
Submitted by andreychek on Wed, 08/24/2016 - 12:03 Comment #5
Yup, that looks good!
Okay, how about this... can you create a new file in your public_html dir named "test.php", and inside it, place the following:
<?php phpinfo(); ?>Then, could you share the URL where we can see that script?
virtual server which complains about no MySQL: http://nonblankmedia.com/test.php
virtual server (with "same" configuration) that doesn't complain: http://offnominal.net/test.php
Submitted by andreychek on Wed, 08/24/2016 - 13:49 Comment #7
Hrm, there's something odd about all that... in both cases it's loading the mysql.ini file, but in one case the MySQL extension is present, but in the other it isn't.
At the moment I'm not sure how to explain that :-)
However, you might try this.
In $HOME/etc/php.ini, try adding this line:
extension=mysql.soAnd see if that makes a difference.
no joy... :(
this may be obvious/meaningless, but just to say:
when Server Configuration > Website Options is set to Apache mod_php, Modules for PHP 5 in PHP information are:
apc bcmath bz2 calendar Core ctypecurl date dba dom ereg exif
fileinfo filter ftp gd gettext hash
iconv imap json ldap libxml mbstring
mcrypt mhash mysql mysqli openssl pcntl
pcre PDO pdo_mysql Phar posix Reflection
session shmop SimpleXML soap sockets SPL
standard suhosin Suhosin sysvmsg sysvsem sysvshm
tokenizer wddx xml xmlreader xmlwriter zip
zlib
when Server Configuration > Website Options is set to FCGId, Modules for PHP 5 in PHP information are:
bcmath bz2 calendar cgi-fcgi Core ctypedate dba dom ereg exif fileinfo
filter ftp gettext hash iconv json
libxml mbstring mhash openssl pcre Phar
posix Reflection session shmop SimpleXML soap
sockets SPL standard sysvmsg sysvsem sysvshm
tokenizer wddx xml xmlreader xmlwriter zip
zlib
i.e. mysql, mysqli, and pdo_mysql are missing (so are curl, gd, imap, ldap, mcrypt, pcntl, PDO, suhosin, and Suhosin)
Also, in case it wasn't clear in my original problem description, there are other virtual servers in the same installation that have Website Options set to FCGId where MySQL is present and WordPress is working.
Submitted by andreychek on Wed, 08/24/2016 - 14:36 Comment #9
If you haven't already, you may want to try restarting Apache. It's possible that you're hitting cached FCGID processes that don't yet have that module enabled.
If that doesn't work, do you see any errors listed in $HOME/logs/error_log when hitting the test.php page?
I did restart Apache after making the change to $HOME/etc/php.ini , and again a little while ago, but it hasn't made a difference.
The domain we're talking about right now is 'nonblankmedia.com'. Bizarrely, there is no file (or rather, symlink) at /home/nonblankmedia/logs/error_log (there is one for the access_log). When I execute the following:
sudo tail /var/log/virtualmin/nonblankmedia.com_error_logI get an empty result.
While this domain is at this time the only one throwing this error on this Virtualmin installation, I have another one where three domains all throw the same error (and 29 do not), and in those error logs I see something like this:
93.219.182.98 - - [24/Aug/2016:13:43:07 -0700] "GET /blog/ HTTP/1.1" 500 374 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:48.0) Gecko/20100101 Firefox/48.0"Submitted by andreychek on Wed, 08/24/2016 - 16:01 Comment #11
Hmm, do you see a corresponding entry in the Apache access log for this domain?
If there isn't an access log entry it may indicate the wrong domain is answering requests there.
Yes, there is an entry in the Apache access log:
93.219.182.98 - - [24/Aug/2016:14:03:59 -0700] "GET / HTTP/1.1" 500 374 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:48.0) Gecko/20100101 Firefox/48.0"It's 11pm here in Berlin and I've got to push away from my desk now. I've enabled Remote Login (referencing this issue, #41811), hoping that perhaps you can look directly for further data and analysis. The failing domain is nonblankmedia.com .
Thanks for all your help!
Submitted by andreychek on Wed, 08/24/2016 - 18:56 Comment #13
There we go, it looks like the extension_dir setting in that domain's php.ini file pointed to a location that didn't exist.
Was that domain perhaps migrated from another server? One explanation for that is that the other server used a different extension directory.
But that appears to be working now, let us know if that did the trick!
Yup, that did indeed do the trick!
Some of the affected domains were indeed transferred, but between various Virtualmin installations I have (I manage six of them atm.)
I've got a bunch more switches from Apache mod_php to FCGId to do, but now that I have this fix - thanks to you! - I know what to do if any further hiccups of this nature occur.
You can close this issue now.
Thanks again, as ever, for your wonderful support!
Namaste!
Submitted by andreychek on Thu, 08/25/2016 - 10:25 Comment #15
Great, glad to hear that's working!
The PHP module location is set by the distribution vendor. So that could potentially be different depending on the distribution being used.
Another option that I just considered, would be to see if it works to comment out that parameter altogether. I wonder if it would default to the correct directory. Or even if it doesn't, you could always set that parameter in a .ini file located in /etc/ rather than needing to set it for each individual domain. Those are just some options though, any of them should work well.