Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

I have a developer server with CentOS 6.5 and PHP 5.5.11 (latest from REMI repos). Today I did:

yum --enablerepo=remi,remi-php55 update

That updated Apache and some other libraries like Mongo for PHP (PECL I thought). After the update, I restarted my httpd service and noticed that it fails shutting down Apache. "Apparently" starting it again corrected that, but now I've found that the server isn't working - web pages are not served.

Checking the Apache logs shows this line:

PHP Fatal error: PHP Startup: To prevent data corruption, you are not allowed to turn on the mongo.native_long setting on 32-bit platforms in Unknown on line 0

Maybe I can fix this by disabling or uninstalling that extension, but since I'm using the extension in some places, that's not really an option.

Any advice on how to fix this issue, other than disabling the extension?

EDIT: Why if system is i686 and library is i686 I got that error

I did some research on YUM logs and see results:

tail /var/log/yum.log
Apr 03 01:25:45 Updated: php-recode-5.5.11-1.el6.remi.i686
Apr 03 01:25:45 Updated: php-mbstring-5.5.11-1.el6.remi.i686
Apr 03 01:25:46 Updated: php-intl-5.5.11-1.el6.remi.i686
Apr 03 01:25:47 Updated: php-xml-5.5.11-1.el6.remi.i686
Apr 04 09:09:59 Updated: krb5-libs-1.10.3-15.el6_5.1.i686
Apr 04 09:10:00 Updated: httpd-tools-2.2.15-30.el6.centos.i686
Apr 04 09:10:07 Updated: php-pecl-mongo-1.5.0-1.el6.remi.5.5.i686
Apr 04 09:10:15 Updated: httpd-2.2.15-30.el6.centos.i686
Apr 04 09:10:16 Updated: krb5-workstation-1.10.3-15.el6_5.1.i686
Apr 04 09:10:21 Updated: krb5-devel-1.10.3-15.el6_5.1.i686

Why if the library is php-pecl-mongo-1.5.0-1.el6.remi.5.5.i686 I was getting that error? What is wrong?

EDIT 2: downgrade the problematic extension

Since previous test didn't work I'm trying now to downgrade that library as follow:

yum downgrade php-pecl-mongo-1.5.0-1.el6.remi.5.5.i686 --enablerepo=remi,remi-php55
Loaded plugins: fastestmirror, security
Setting up Downgrade Process
Loading mirror speeds from cached hostfile
 * base: centos.secrel.com.br
 * epel: mirror.cedia.org.ec
 * extras: centos.secrel.com.br
 * remi: mirror.1000mbps.com
 * remi-php55: mirror.1000mbps.com
 * updates: mirrors.ucr.ac.cr
Only Upgrade available on package: php-pecl-mongo-1.5.0-1.el6.remi.5.5.i686
Nothing to do

And I can't, so any help on this one too?

EDIT3: Looking for php.ini location

So since Ubuntu and CentOS has different configuration, I tough that Apache could be using another php.ini file but it uses what I changed, see below:

locate php.ini
/etc/php.ini
/etc/php.ini.rpmnew
/usr/share/doc/php-common-5.5.11/php.ini-development
/usr/share/doc/php-common-5.5.11/php.ini-production
/var/www/html/apps/portal_de_logistica/vendor/doctrine/cache/tests/travis/php.ini
/var/www/html/apps/portal_ingenieros/vendor/doctrine/cache/tests/travis/php.ini
/var/www/html/imaginamos/vendor/doctrine/cache/tests/travis/php.ini
/var/www/html/kraken/vendor/doctrine/cache/tests/travis/php.ini

In /etc/php.ini I have this at file end:

;Mongo
[mongodb]
mongo.native_long = 0
mongo.long_as_object = 1

Also I found any file that might cause the problem by doing a ini_set() and nothing was found as can see below:

grep -R "mongo.native_long" /var/www/html/
grep: /var/www/html/apps/portal_de_logistica/web/bundles/acmedemo: No such file or directory

Solution

So, after some headaches I found the solution:

yum remove php-pecl-mongo-1.5.0-1.el6.remi.5.5.i686
yum --enablerepo=remi,remi-php55 install php-devel.i686
pecl install mongo

Add "extension=mongo.so" to php.ini after that my Apache works again

share|improve this question
    
Are you actually using x64? Remove the 32 bit php packages and install the x64 packages. –  NickW Apr 4 at 14:33
    
@NickW what command I should run to know if my system is x64 or 32? –  ReynierPM Apr 4 at 14:35
    
uname -a is usually enough.. if it's 64 bit you'll see x86_64 –  NickW Apr 4 at 14:36
    
This is the result for that command Linux devserver 2.6.32-431.11.2.el6.i686 #1 SMP Tue Mar 25 17:17:46 UTC 2014 i686 i686 i386 GNU/Linux it's 64 or x86_64? –  ReynierPM Apr 4 at 14:37
2  
i686 means a 32 bit kernel, I'd follow JakeGould's advice.. but if you want to make proper use of mongoDB, you'll need a 64 bit OS. –  NickW Apr 4 at 14:39

2 Answers 2

up vote 3 down vote accepted

Your error reads:

PHP Fatal error: PHP Startup: To prevent data corruption, you are not allowed to turn on the mongo.native_long setting on 32-bit platforms in Unknown on line 0

The key here is the mongo.native_long setting. Seems like your OS is 32-bit, but this specific setting requires a 64-bit OS. The best long-term solution for you if this is a development server is to rebuild it as a 64-bit OS.

The more immediate option is to go into your php.ini file & disable mongo.native_long—not all of MongoDB—by placing this configuration parameter in php.ini like so:

mongo.native_long = 0

And now restart Apache. Things should work. That is assuming the specific functionality of mongo.native_long is not needed by anything in your codebase. For more details on MongoDB configuration, check out the official documentation here. And for more details on mongo.native_long, this blog entry seems to be pretty helpful:

On 64-bit platforms, the mongo.native_long setting allows for 64-bit integers to be stored in MongoDB. The MongoDB data type that is used in this case is the BSON LONG, instead of the BSON INT that is used if this setting is turned off. The setting also changes the way how BSON LONGs behave when they are read back from MongoDB. Without mongo.native_long enabled, the driver would convert every BSON LONG to a PHP double which results in the loss of precision.

share|improve this answer
    
Is not needed but I did things as you suggest and didn't work, Apache still not working –  ReynierPM Apr 4 at 14:38
1  
Ok, I'll setup a new test server with x64. This DVD CentOS-6.5-x86_64-bin-DVD1.iso and CentOS-6.5-x86_64-bin-DVD2.iso should have this release right? –  ReynierPM Apr 4 at 14:40
    
So you rebuilt your 32-bit OS into 64-bits already? Probably not. You attempted the MongoDB tweak, which is fair because it’s the simplest, quickest way to attempt to clear up the issue. But it seems that your best long term solution to this issue is to rebuild the OS as 64-bit to begin with. And yes, x86_64 indicates the OS iso images you have are 64-bit installs. –  JakeGould Apr 4 at 14:41
    
Ups ... my office PC doesn't support 64 bits, any other solution on this new problem rarer than install x86_64 OS? How do I upgrade Mongo library to fix the issue? –  ReynierPM Apr 4 at 14:56
1  
Well I'll tell that to my boss hehehehe at home I have 64 bits, maybe this core is not capable for this architecture, thanks –  ReynierPM Apr 4 at 15:00

Your error seems to be seems to be related to this update of the mongo php driver: https://jira.mongodb.org/browse/PHP-971 (if you look at the error in the git commit, it's exactly that).

If you have set mongo.native_long to 0, but you are still getting the error, have a look in any php scripts or php pages, and see if they have ini_set('mongo.native_long', 1); at the top (considering it's complaining about line 0).

share|improve this answer
    
Hmm I check my code (using Netbeans search, doesn't know if is the best approach and don't know if I can find from Linux command line I mean don't know any command able to do that) and that is not present. I also tried to downgrade the library and can't see question edition –  ReynierPM Apr 4 at 15:58
    
Not just your code, any php code under the /var/www/ directory on the machine. It's obviously somewhere.. –  NickW Apr 4 at 16:02
    
I'm running this command grep -R "mongo.native_long" /var/www/html/ is where I think that directive could be enabled, how do I know which php.ini file Apache is using? –  ReynierPM Apr 4 at 16:02
    
the line of code I mentioned could be in any .php file, for example an index.php. Usually apache uses /etc/php.ini, but you can be sure by running this: php -i | grep "Loaded Configuration File" –  NickW Apr 4 at 16:06
    
Yes, for that reason I run the command under /var/www/html it's where .php files reside, command still running. I made a new edition referencing php.ini location –  ReynierPM Apr 4 at 16:09

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.