Can someone else please chip in with some advice? I can't do this on my own.
KB - you've got some stuff going on here that's very confusing. It is causing me to slightly lose the plot.
So, we'd better get a few things straight before we proceed.
You mentioned in a PM that you had a container with a fresh install, and obviously there's also the container with the upgraded 5.1.6 to 5.3.14.
We need to stick to one or the other of these because I'm finding it difficult to tell which one we are talking about at any one time.
For example, in your last post you show a php -v where php 5.3.3 with IonCube loaded is installed. Is this is the stock Centos 6 version of php, and therefore the clean install? I thought it was, but then you mentioned using old .ini files, which implies it might be an upgrade. So I'm confused again.
[Incidentally, at one point you appeared to be confusing Zend Engine with Zend Optimizer a couple of times -- but maybe it was just a typo? When you see something that's version 2.3.0, that's the Zend Engine and is what you are supposed to have and will be there by default]
So let's stick to the upgraded container that went from 5.1.6 to 5.3.14.
That's the one with the sqlite3.so error and the one where people with ZendGuard/ZendEncoder-encoded code are seeing the worrying error message and therefore the one that's important as far as I can tell.
In that one, php -v from the command line gives you:
Code: Select all
PHP Warning: PHP Startup: Unable to load dynamic library '/usr/lib64/php/modules/sqlite3.so' - /usr/lib64/php/modules/sqlite3.so: undefined symbol: sqlite3_stmt_readonly in Unknown on line 0
PHP 5.3.14 (cli) (built: Jun 14 2012 16:34:56)
Copyright (c) 1997-2012 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2012 Zend Technologies
with the ionCube PHP Loader v4.0.10, Copyright (c) 2002-2011, by ionCube Ltd., and
with Zend Guard Loader v3.3, Copyright (c) 1998-2010, by Zend Technologies
Note that in your last post you did a "locate sqlite.so" but the file in question is sqlite3.so. Also I don't know which system you did that locate on - fresh or upgraded.
If you look for sqlite3.so on an atomic 5.3.14 system it should look like this:
Code: Select all
# locate sqlite3.so
/usr/lib64/libsqlite3.so.0
/usr/lib64/libsqlite3.so.0.8.6
/usr/lib64/php/modules/sqlite3.so
/usr/lib64/php-zts/modules/sqlite3.so
/usr/lib64/python2.6/lib-dynload/_sqlite3.so
/usr/lib64/sw/sqlite37/libsqlite3.so.0
/usr/lib64/sw/sqlite37/libsqlite3.so.0.8.6
/var/asl/usr/lib64/php/modules/sqlite3.so
/var/asl/usr/lib64/php-zts/modules/sqlite3.so
#ls -al /usr/lib64/php/modules/sqlite3.so
-rwxr-xr-x 1 root root 48464 Jun 14 21:45 /usr/lib64/php/modules/sqlite3.so
As for ZendGuard....the output of php -v indicated Zend Guard Loader is loaded. So there should not be any Zend Guard errors from applications. But somehow your customers are getting them. I do not understand that.
Do you get the same output confirming ZendGuard is loaded when you look at a php page with phpinfo() in it on an actual website on the server?
Also take a look in /etc/php.d/ and look for things that are NOT in the list I posted or are older than the upgrade date.
For example, might there be a zend-optimizer.ini or something in there, trying to load something it shouldn't?
Is there an .ini in there that's trying to load a version of sqlite3.so that it shouldn't?
Finally, I don't suppose it is beyond the realms of possibility that your customer is using a script that's incompatible with 5.3 or that the script somehow doesn't work with the latest ZendGuard Loader.
The only thing that bothers me is that the RPM says "php-zend-guard-loader-5.5.0" while the ZendGuard Loader is listed as 3.3 in php -v (on my systems too -- this is not just yours). This may be perfectly normal, but seems a little odd to me.
*** You can always try installing the loader manually from the file you can download from the Zend website (but remove the rpm version first or at least make sure two aren't trying to be loaded).
I'm now at the end of my suggestion list - I've got nothing more. And this is taking far too long to do by posts and stuff and there's no guarantee anybody is going to be able to help in this way.
I think it would be far better to get someone to take a look at your system and resolve the problem for you. I can't imagine it will take an expert very long to figure out. And I'm not talking about me. Breun was offering professional services at one time, particularly related to Plesk. I don't know if he still does or if this comes under what his company is williing to do. The Promethius/Atomicorp guys know it all and then some, of course. There are undoubtedly others on the forum too.
Faris.