php modules not being included

After my box received an auto update today, apache was restarted, and this caused a problem with php sites connecting to mysql.

The sites error log was showing this for each attempted connection:
PHP Fatal error: Call to undefined function: mysql_pconnect() in /home/…

The /etc/php.d/mysql.ini file was present, correct and being included (according to a php_info() page. (additional .ini files parsed /etc/php.d/imap.ini, /etc/php.d/ldap.ini, /etc/php.d/mysql.ini)
Yet mysql’s module was not being loaded (no mysql section on page, and the error above).

The only update I received today was one to fix yesterdays permissions problem (which I’d already fixed and is unrelated to this one), so I looked to the previous days upgrade of php from 4.3.8 to 4.3.9.

The /etc/php.ini file in 4.3.8 had:

; Directory in which the loadable extensions (modules) reside.
extension_dir = /usr/lib/php4

Present so it was ok, yet the 4.3.9 rpm’s (and my current) php.ini file had:

; Directory in which the loadable extensions (modules) reside.
extension_dir = "./"

To verify this was incorrect, I tailed the /var/log/httpd/error_log file and saw this when I restarted apache.

PHP Warning:  Unknown(): Unable to load dynamic library './imap.so' - ./imap.so: cannot open shared object file: No such file or directory in Unknown on line 0
PHP Warning:  Unknown(): Unable to load dynamic library './ldap.so' - ./ldap.so: cannot open shared object file: No such file or directory in Unknown on line 0
PHP Warning:  Unknown(): Unable to load dynamic library './mysql.so' - ./mysql.so: cannot open shared object file: No such file or directory in Unknown on line 0

Simply changing the extension_dir to /usr/lib/php4 (and checking the files were in that folder) and restarting apache (service httpd restart) all was good again.

Again I hope this change is correct, and might help others if their boxes exhibit the same errors. (I’m on Redhat9 by the way.)

Not quite sure whats going on with the updates lately. Do you guys need more testers ?

Thanks again,
Robert Harrison
http://whitellama.net

We’ve seen this on a few other boxes robert and your fix was correct. And yes, we’re always in need of testers and would be grateful if you’d like to BETA any new releases. The problem didn’t show up on our test boxes and even our live boxes before release but it’s clear that we missed something and a broader external BETA base is obviously a help, and I thank you.

Chris

very good analysis Robert, much more explicit mine.

if at least I had readen your post 2/3 hours before I look into my log, conf files, … I’d not lost time :eek:

Next time I’ll look at the right place in the forum :wink:

Pascal

Updated my two machines with this fix. :slight_smile:

I think the Iworx Team should include this fix in an update pack (even if it’s minor) because I’ve gone mad looking all over the place for the fix!!! I think small fixes should be addressed ASAP. Best regards!

They do .1 .2 etc releases when the bug or bugs theyfix are a serious enough. Not sure if a bug fix of conveinence qualifies.

This was still a problem, this thread was back from 2004?

I don’t think it was Justin, he’s got a ticket open and we’re checking it out but all new installs as of months ago had this fix.

Chris

My machine had this bug. Could it be because I used the 64 bit version of Centos 4.2? :wink:

It’s possible Poooh, I’ll check it out for that release.

Chris

We installed a 64-bit CentOS 4.2 box the other day Poooh and it didn’t have the php.ini issue. Our SRPM shared the php.ini between all releases as well so I’m stumped, but glad you got it fixed.

Chris