Apache doesn't load PHP MySQL extension but IIS does

Question

I have a really irritating problem with PHP on Windows Server 2008 R2. IIS and Apache are running on the same machine (Apache is embedded with another product and it being there is not my choice).

IIS is configured to be able to use multiple versions of PHP, and none of the PHP versions on there were installed with the Windows installer (so php.exe does not exist in the path).

Apache uses one particular version of PHP (5.2.5 Thread-safe - again I can't change this as a 3rd-party application has PHP extensions compiled against this version).

If I check phpinfo() in my Apache site it doesn't have an entry for MySQL, even though php_mysql.dll is enabled in php.ini and it exists in the \ext directory. If I (temporarily) add this version of PHP (same directory, same php.ini) to IIS and set up a test site with phpinfo() it correctly lists MySQL. I know this is not just some strange issue with phpinfo because I have a MySQL-based PHP site running in Apache and it fails with Call to undefined function mysql_connect()

It was suggested that I copy libmysql.dll from the PHP directory to C:\Windows\System32 but this made no difference. As there are multiple versions of PHP on the server I suppose it's possible that the wrong version of libmysql.dll is being loaded, but the PATH doesn't include any directories containing libmysql.dll.

IIS and Apache are looking at exactly the same PHP installation, php.ini, and ext directory, but only IIS can load the MySQL extension. Apache is on the default System account as it looks like System has access to all the DLLs.

The Apache logs say nothing about any DLLs failing to load. I'm logging PHP errors in the event log but nothing is reported about those extensions.

After Googling around the issue I found other suddenly-occurring issues in PHP on Windows server but the usual resolutions - rebuilding php.ini, restarting IIS, restarting the server - haven't helped.

Any suggestions on where to look next are much appreciated!

Damaris

Did you check that the DLLs from c:\%php_5.2.5_install_path$\ are are copied to C:\Windows\System32 ? For example 'libmysql.dll' or 'libmhash.dll'. I know this is needed for Apache+PHP, not sure for IIS+PHP – Siegfried

@Siegfried this sounds promising, but I also have PHP 5.3.10 working in IIS and it currently has no problems connecting to MySQL. Is there a risk that copying the 5.2.5 DLLs to System32 will adversely affect 5.3.10? – Damaris

If there are already the 5.3.10 DLLs in System32, yes there is a risk to affect PHP 5.3.10 – Siegfried

unfortunately copying libmysql.dll didn't fix the issue, but I did discover that elsewhere on the server there are several files with the same name. For example MySQL workbench has one. MySQL workbench is on the path, so maybe this DLL is being loaded by PHP 5.2.5? C:\Windows\System32 is the first entry on the path and MySQL workbench is near the end, so I would expect the DLL I copied to System32 to take priority - maybe this is not the case? – Damaris

What modules have you loaded? A lot of them don't appear under the Additional Modules header (is this the list you're talking about?) My own list using php_info() is empty but if I use get_loaded_extensions() I have a list of 35 modules. I believe the "Additional Modules" refers to third-party modules? – Wofford

@MichaelRushton yes sorry the additional modules section was a red herring, there is also a 3rd-party plugin involved but that doesn't seem to have a problem. Under IIS MySQL has its own section in the phpinfo response, but in Apache it doesn't - even though everything is the same for both servers. – Damaris

Are you executing PHP through mod_php or FastCGI ? Did you make your modifications to the php.ini file specified in the phpinfo() page ? – Droplet

@Pierre-OlivierBourgeois when this version is running through IIS (which it is only temporarily, for testing this problem) it's through FastCGI. In Apache - where it runs permanently - I'm not exactly sure how it's executed. httpd.conf contains this: LoadModule php5_module modules/php5apache2_2.dll Also, yes the php.ini location reported in phpinfo is definitely the file I'm editing – Damaris

Is there a php.exe file in wherever your Apache server is loading php5apache2_2 from? If you find it, it should be easier to test your way around and check where PHP is looking for php_mysql.dll. ListDLLs and Process Explorer may be of some help – Bumf

Answer 1

Ultimately this issue came down to a missing PATH reference. Although IIS doesn't seem to require PHP or PHP modules to exist in the path it seems that Apache (or perhaps my version of PHP?) does. I am lucky in that I only need to run one version of PHP outside IIS, as I have no idea what would happen if I had multiple Apache instances referencing different versions of PHP and multiple PHP directories in the path - presumably one would always fail.

So far it looks like adding Apache's version of PHP to the path hasn't affected the IIS versions of PHP, but I will swear loudly if it suddenly does.

Damaris

Answer 2

I know this might not ultimately answer your question but, did you try configuring Apache to execute PHP through FastCGI (mod_fcgid) and use the same binary as IIS does ?

I know you are using mod_php, but calling it via FastCGI will abstract PHP from the webserver process. If extensions are loading fine under PHP called via FastCGI, there is no reason it won't work on a different web server.

Also, I personally beleive that it is a better idea this way since PHP is only called when a *.php file is requested. This way, Apache will not load PHP in memory for every request, which will give you better performance for serving static files, for example.

Update

To do this, you need to download mod_fcgid from http://httpd.apache.org/mod_fcgid/, load the module in your Apache configuration this way,

LoadModule fcgid_module modules/mod_fcgid.so  

And then, just specify what binary you want to call when PHP pages are requested:

AddHandler fcgid-script .php  
FcgidWrapper "c:/php/php-cgi.exe" .php  

Then, files with a .php extension will now be executed by the PHP FastCGI wrapper. Just be sure to specify the same php-cgi.exe binary as IIS is using.

All extensions that were previously available in IIS should now be available in Apache since the PHP installation behind is the same in both environment.

Keep me updated.

Droplet

Thanks for this - can you give any hints on how I would configure apache to use CGI? – Damaris

great thanks for the update. I can't test this change within office hours (PST) so I will give it a go over the weekend – Damaris

@tomfumb: Did you had the chance to test my proposition ? – Droplet

Sorry for the delay, I didn't actually need to try it in the end (though I do appreciate your input) as I finally figured out the source of the issue. None of the answers accurately described the issue so it will be misleading to others to mark anything as correct – Damaris

Answer 3

1.- check php.ini path in phpinfo.

2.- add php folder to the windows path

http://www.computerhope.com/issues/ch000549.htm

3.- add directive PHPINIDir to apache conf

http://php.net/manual/en/install.windows.apache2.php

4.- uncomment mysql extension in respective php.ini

5.- reload apache

6.- check mysql extension in phpinfo

and please don't copy any files to system32

Cystotomy

Answer 4

You will generally need different library dlls for the different versions of PHP you are running. It's best to keep these in their own directories.

There's a few different things that could cause a module not to load, including the PHP version whether you're running a thread-safe or not-thread-safe version and also if the binaries were compiled as VC6 or VC9 †. Usually the easiest way to debug if you're getting any module loading errors is running php.exe from the command line as it will spit out any startup errors (also ensure these are enabled in your php.ini and you're loading the correct php.ini file when you do so).

† IIRC VC6/VC9 is to do with which version of Visual Studio PHP was compiled with.

Rascally

thanks for the suggestion, if I had thought of this earlier it probably would have helped as I should have seen an error saying that php_mysql.dll could not be found – Damaris

No problem, from your follow up answer I might suggest setting the extension_dir (either just the dir name off your php folder or the full c:\ path to the folder) in your php.ini file rather than using PATH. These should be specific to each php instance and should point to the directory containing the DLLs for that PHP. FWIW PATH is hierarchical so Windows will use the first folder in the list that contains the file it's looking for, which will, as you say, likely cause you issues when running multiple versions of PHP. – Rascally

also for future reference there's more help here: php.net/manual/en/install.windows.extensions.php – Rascally