PDO_MYSQL extension Nightmare

[vacunita]

I'm pulling my hair out on this one. Maybe you can help me out here jpadie, and we can help future posters.

The issue in a nutshell is the PDO_MYSQL extension is unstable, and at times its not getting loaded. What happens is the sites relying on it are issuing an error to the effect of

PDOException: could not find driver in /mnt/http/siteaddress/public/site/classes/class.base.php on line 189

Line 189 is where the PDO class is instantiated. Why its doing this I do not know. If I run a phpinfo() I can see the extension is loaded sometimes, but not loaded others as I keep refreshing. I find it extremely odd. And cannot find why its doing this.

Any ideas no matter how far fetched?

----------------------------------
Phil AKA Vacunita
----------------------------------
Ignorance is not necessarily Bliss, case in point:
Unknown has caused an Unknown Error on Unknown and must be shutdown to prevent damage to Unknown.

Web & Tech

 

[jpadie]

Phil I have never had that happen.

There were some reports about a release of mysqlnd being a bit buggy. But that was a nightly build from memory. If you're running on Linux and installed via apt could it be a buggy package? Perhaps an apt-update apt-upgrade would move things to a different point version. Or better still deinstall the package and then recompile the native driver by hand.

I'd also consider wrapping the driver instantiation in some conditionals to make sure it exists then log each instance of problem together with output from selective output from.php.ini. I'm wondering whether there might be thread issues or perhaps different php.ini files are being used if this is behind a squid server or whatever. But anyway logging the env cars and other useful info will be interesting to see the differences between a healthy load and an unhealthy load.

 

[vacunita]

Yes, This is running on Centos. Its a client's server, so not all that much control over it. I'm just providing the Application. I'm still trying to locate the PHP logs in this server its really a mess how its set up.



----------------------------------
Phil AKA Vacunita
----------------------------------
Ignorance is not necessarily Bliss, case in point:
Unknown has caused an Unknown Error on Unknown and must be shutdown to prevent damage to Unknown.

Web & Tech

 

[vacunita]

After several restarts, PHP seems to not want to parse the pdo_mysql.ini file for some reason.
Its in the directory for additional ini files to parse, and contains the line extension=pdo_mysql.so

The pdo_mysdl.so file exists in usr/lib64/php

Not sure what else to try.

Platform is: Centos 5


----------------------------------
Phil AKA Vacunita
----------------------------------
Ignorance is not necessarily Bliss, case in point:
Unknown has caused an Unknown Error on Unknown and must be shutdown to prevent damage to Unknown.

Web & Tech

 

[vacunita]

Finally found an error log:

And the error is:

PHP Startup: Unable to load dynamic library '/usr/lib64/php/modules/pdo_mysql.so' - /usr/lib64/php/modules/pdo_mysql.so: undefined symbol: php_pdo_get_dbh_ce in Unknown on line 0

----------------------------------
Phil AKA Vacunita
----------------------------------
Ignorance is not necessarily Bliss, case in point:
Unknown has caused an Unknown Error on Unknown and must be shutdown to prevent damage to Unknown.

Web & Tech

 

[jpadie]

sounds like the wrong extension version for the core. might there be more than one instance of php installed? i guess I'd go for the wipe clean and rebuild route.

 

[vacunita]

If only.... So many other things running there, I'm not sure a rebuild is the way to go. Might impact other things if I change versions.

I'm thinking of rewriting the base code to use mysqli instead of PDO.

----------------------------------
Phil AKA Vacunita
----------------------------------
Ignorance is not necessarily Bliss, case in point:
Unknown has caused an Unknown Error on Unknown and must be shutdown to prevent damage to Unknown.

Web & Tech

 

[jpadie]

not sure that would help you if the underlying library (mysqlnd) is fubar.

i wonder whether it's a 32 vs 64 bit issue?
i suggest you do something like this

yum remove php-mysql
yum remove php-pdo
yum update
yum install php-pdo
yum install php-pdo

 

[vacunita]

I've removed PDO a couple times already and it hasn't helped.

The underlying library seems to be o.k, as I can use mysqli without errors.

Not sure what else to check without recreating their server, which I really don't want to do, nor do I think thye want that either.

I put together a quick mysqli based ... err... base method and so far its error free. I'll need to change somethings that rely on the prepare statement, but for now it seems to work o.k.

I'll have to re-implement that later on, fortunately I had a base class that uses mysqli and returns data arrays stashed away for just such an event.


----------------------------------
Phil AKA Vacunita
----------------------------------
Ignorance is not necessarily Bliss, case in point:
Unknown has caused an Unknown Error on Unknown and must be shutdown to prevent damage to Unknown.

Web & Tech

 

[jpadie]

from a brief look at the source the symbol is defined in the pdo shared object. so it is this object that is not loaded when pdo_mysql is trying to load.

so some thoughts:

1. with these nasty symlinked loaders that centos use, are you certain that the pdo_mysql shared object is being loaded only after the pdo object is loaded? or perhaps force the issue by putting the pdo shared object into the top of the pdo_mysql.ini file. or even neater, rename pdo_mysql.ini as xpdo_mysql.ini and restart the web server.

2. make sure that there are not any other framework type extensions that use pdo or pdo_mysql that are loaded too early. session managers for example if these are dl()ing the pdo_mysql object without first checking that pdo.so is loaded then that could be a cause too.[ul]
[li][/li]
[/ul]

 

[jpadie]

having slept on it, I think item 1 is most likely to be the issue.

 

[vacunita]

I was thinking the same thing. And did try renaming the ini file as well as the .so extension file, and it didn't help.

I've requested their Sys Admin's schedule a rebuild of their server. When that happens I can try again. As it is I've spent way to much time on this, and there's delivery deadline for the services. So we need to move on with mysqli for now.





----------------------------------
Phil AKA Vacunita
----------------------------------
Ignorance is not necessarily Bliss, case in point:
Unknown has caused an Unknown Error on Unknown and must be shutdown to prevent damage to Unknown.

Web & Tech

 

[jpadie]

Good time to rebuild today as openssl will need to be recompiled and thus Apache and php rebuilt against it to protect against heartbleed. And keys regenerated of course.

 

[vacunita]

Its up to them now to rebuild. When they do, I'll check out the PDO install once more.

But yes, I'll have to rebuild my own Production server later today. Ughhh...

----------------------------------
Phil AKA Vacunita
----------------------------------
Ignorance is not necessarily Bliss, case in point:
Unknown has caused an Unknown Error on Unknown and must be shutdown to prevent damage to Unknown.

Web & Tech

 

[vacunita]

It was good to toss around ideas with you. It let me know I wasn't completely overlooking something. Thanks.

----------------------------------
Phil AKA Vacunita
----------------------------------
Ignorance is not necessarily Bliss, case in point:
Unknown has caused an Unknown Error on Unknown and must be shutdown to prevent damage to Unknown.

Web & Tech

 

[jpadie]

I guess more for other readers but you could always check whether PDO was loaded and if not dl() it (if your installation is not >=5.3)