0

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

ReynierPM
  • 710
  • 5
  • 14
  • 30
  • Are you actually using x64? Remove the 32 bit php packages and install the x64 packages. – NickW Apr 04 '14 at 14:33
  • @NickW what command I should run to know if my system is x64 or 32? – ReynierPM Apr 04 '14 at 14:35
  • `uname -a` is usually enough.. if it's 64 bit you'll see x86_64 – NickW Apr 04 '14 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 04 '14 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 04 '14 at 14:39
  • What's wrong is that the `mongo.native_long` is 64 bit only, maybe it was unset earlier, maybe it was ignored, maybe it is part of some new package you just installed.. – NickW Apr 04 '14 at 15:38
  • @NickW I can't disable it trough `php.ini` tried with `[mongodb] mongo.native_long = 0`, `[mongodb] mongo.native_long = false` and none works, Apache doesn't start, any other advice at least to fix the issue at this moment? – ReynierPM Apr 04 '14 at 15:42

2 Answers2

3

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.

Giacomo1968
  • 3,542
  • 27
  • 38
  • Is not needed but I did things as you suggest and didn't work, Apache still not working – ReynierPM Apr 04 '14 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 04 '14 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. – Giacomo1968 Apr 04 '14 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 04 '14 at 14:56
  • I would recommend doing a clean install then in 32-bit & then explicitly install the 32-bit MongoDB on top of that. But also—in all honesty—64-bit OS is the way things are going so it might be best to seek out a 64bit capable machine. – Giacomo1968 Apr 04 '14 at 14:59
  • 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 04 '14 at 15:00
  • If you want to do real life things with mongoDB, tell your boss that 64bit is a necessity. – NickW Apr 04 '14 at 15:01
  • Hmm this is a development enviroment, in our dedicated server we have 64 bits ;) but anyway I'll tell, thanks for your help – ReynierPM Apr 04 '14 at 15:02
  • “…in our dedicated server we have 64 bits.” Even more of a reason. Your development environment should be as 1-to-1 on par OS-wise as your production environment. – Giacomo1968 Apr 04 '14 at 15:29
  • See my edit @JakeGould I get lost at this point – ReynierPM Apr 04 '14 at 15:33
  • I don’t know. But it seems like all of your solutions will be solved by a 64-bit OS install. – Giacomo1968 Apr 04 '14 at 15:48
1

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).

NickW
  • 10,263
  • 1
  • 20
  • 27
  • 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 04 '14 at 15:58
  • Not just your code, any php code under the /var/www/ directory on the machine. It's obviously somewhere.. – NickW Apr 04 '14 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 04 '14 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 04 '14 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 04 '14 at 16:09
  • This works for me, i have changed value from 1->0 – hemc4 Apr 24 '14 at 13:26