Topic: PHP 5.3.6-4 builds broken

We just upgraded a server that had the following RPMs installed:

php-common-5.3.6-1.el5.remi
php-mysql-5.3.6-1.el5.remi
php-5.3.6-1.el5.remi
php-tidy-5.3.6-1.el5.remi
php-pear-1.9.2-3.el5.remi
php-cli-5.3.6-1.el5.remi
php-mbstring-5.3.6-1.el5.remi
php-gd-5.3.6-1.el5.remi
php-pgsql-5.3.6-1.el5.remi
php-imap-5.3.6-1.el5.remi
php-pdo-5.3.6-1.el5.remi
php-mcrypt-5.3.6-1.el5.remi
php-xml-5.3.6-1.el5.remi


Now the server has the following:

php-common-5.3.6-4.el5.remi
php-pdo-5.3.6-4.el5.remi
php-mbstring-5.3.6-4.el5.remi
php-xml-5.3.6-4.el5.remi
php-pear-1.9.2-3.el5.remi
php-cli-5.3.6-4.el5.remi
php-5.3.6-4.el5.remi
php-mysql-5.3.6-4.el5.remi
php-gd-5.3.6-4.el5.remi
php-mcrypt-5.3.6-4.el5.remi
php-tidy-5.3.6-4.el5.remi
php-pgsql-5.3.6-4.el5.remi
php-zts-5.3.6-4.el5.remi


As a result, Apache doesn't respond (processes are present though). The Apache error_log shows the following:

PHP Warning:  PHP Startup: Unable to load dynamic library '/usr/lib64/php/modules/
curl.so' - /usr/lib64/php/modules/curl.so: undefined symbol: file_globals in Unkno
wn on line 0
PHP Warning:  PHP Startup: Unable to load dynamic library '/usr/lib64/php/modules/
dom.so' - /usr/lib64/php/modules/dom.so: undefined symbol: executor_globals in Unk
nown on line 0
PHP Warning:  PHP Startup: Unable to load dynamic library '/usr/lib64/php/modules/
fileinfo.so' - /usr/lib64/php/modules/fileinfo.so: undefined symbol: file_globals
in Unknown on line 0
PHP Warning:  PHP Startup: Unable to load dynamic library '/usr/lib64/php/modules/
gd.so' - /usr/lib64/php/modules/gd.so: undefined symbol: core_globals in Unknown o
n line 0
PHP Warning:  PHP Startup: Unable to load dynamic library '/usr/lib64/php/modules/
json.so' - /usr/lib64/php/modules/json.so: undefined symbol: executor_globals in U
nknown on line 0
PHP Warning:  PHP Startup: Unable to load dynamic library '/usr/lib64/php/modules/
mbstring.so' - /usr/lib64/php/modules/mbstring.so: undefined symbol: sapi_globals
in Unknown on line 0
PHP Warning:  PHP Startup: mcrypt: Unable to initialize module\nModule compiled wi
th build ID=API20090626,NTS\nPHP    compiled with build ID=API20090626,TS\nThese o
ptions need to match\n in Unknown on line 0
PHP Warning:  PHP Startup: Unable to load dynamic library '/usr/lib64/php/modules/
mysql.so' - /usr/lib64/php/modules/mysql.so: undefined symbol: executor_globals in
Unknown on line 0
PHP Warning:  PHP Startup: Unable to load dynamic library '/usr/lib64/php/modules/
mysqli.so' - /usr/lib64/php/modules/mysqli.so: undefined symbol: executor_globals
in Unknown on line 0
PHP Warning:  PHP Startup: Unable to load dynamic library '/usr/lib64/php/modules/
pdo.so' - /usr/lib64/php/modules/pdo.so: undefined symbol: executor_globals in Unk
nown on line 0
PHP Warning:  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_reg
ister_driver in Unknown on line 0
PHP Warning:  PHP Startup: Unable to load dynamic library '/usr/lib64/php/modules/
pdo_pgsql.so' - /usr/lib64/php/modules/pdo_pgsql.so: undefined symbol: file_global
s in Unknown on line 0
PHP Warning:  PHP Startup: Unable to load dynamic library '/usr/lib64/php/modules/
pdo_sqlite.so' - /usr/lib64/php/modules/pdo_sqlite.so: undefined symbol: executor_
globals in Unknown on line 0
PHP Warning:  PHP Startup: Unable to load dynamic library '/usr/lib64/php/modules/
pgsql.so' - /usr/lib64/php/modules/pgsql.so: undefined symbol: executor_globals in
Unknown on line 0
PHP Warning:  PHP Startup: Unable to load dynamic library '/usr/lib64/php/modules/
phar.so' - /usr/lib64/php/modules/phar.so: undefined symbol: sapi_globals in Unkno
wn on line 0
PHP Warning:  PHP Startup: Unable to load dynamic library '/usr/lib64/php/modules/
tidy.so' - /usr/lib64/php/modules/tidy.so: undefined symbol: core_globals in Unkno
wn on line 0
PHP Warning:  PHP Startup: Unable to load dynamic library '/usr/lib64/php/modules/
wddx.so' - /usr/lib64/php/modules/wddx.so: undefined symbol: executor_globals in U
nknown on line 0
PHP Warning:  PHP Startup: Unable to load dynamic library '/usr/lib64/php/modules/
xmlreader.so' - /usr/lib64/php/modules/xmlreader.so: undefined symbol: executor_gl
obals in Unknown on line 0
PHP Warning:  PHP Startup: xmlwriter: Unable to initialize module\nModule compiled
with build ID=API20090626,NTS\nPHP    compiled with build ID=API20090626,TS\nThes
e options need to match\n in Unknown on line 0
PHP Warning:  PHP Startup: Unable to load dynamic library '/usr/lib64/php/modules/
xsl.so' - /usr/lib64/php/modules/xsl.so: undefined symbol: executor_globals in Unk
nown on line 0
PHP Warning:  PHP Startup: Unable to load dynamic library '/usr/lib64/php/modules/
zip.so' - /usr/lib64/php/modules/zip.so: undefined symbol: executor_globals in Unk
nown on line 0


These are the only messages in the error_log that differ from the servers still running 5.3.6-1. It would appear these errors in the 5.3.6-4 PHP build are keeping Apache from processing any kind of requests (even standard html requests.

Re: PHP 5.3.6-4 builds broken

Did you set the "--enable-versioning" flag when you built them? If so, that could be the cause.

Re: PHP 5.3.6-4 builds broken

If seems you are running http in worker mode, so with php-zts, but try to use the standard extension...

Check if the defined value for extension_dir.

There is no change in the build.

P.S. extension_dir don't need to be set, default value is fine.

Desktop: Fedora 33 + rpmfusion + remi-test + remi-dev
Laptop:  Fedora 32 + rpmfusion + remi (SCL only)
Hosting Server: CentOS 8 Stream with EPEL, rpmfusion, remi

Re: PHP 5.3.6-4 builds broken

Remi wrote:

If seems you are running http in worker mode, so with php-zts, but try to use the standard extension...

Check if the defined value for extension_dir.

There is no change in the build.

We already disabled worker mode as part of the troubleshooting (commented the line out of /etc/sysconfig/httpd), but we still have the same issue. The server is now showing apache processes as /usr/sbin/httpd, but Apache just doesn't seem to be responding to requests.
We're baffled.

Re: PHP 5.3.6-4 builds broken

What is the output of

rpm -qa php\*  | sort
rpm -Va php\*
php -v
php -n -v
Desktop: Fedora 33 + rpmfusion + remi-test + remi-dev
Laptop:  Fedora 32 + rpmfusion + remi (SCL only)
Hosting Server: CentOS 8 Stream with EPEL, rpmfusion, remi

Re: PHP 5.3.6-4 builds broken

# rpm -qa php\*  | sort
php-5.3.6-4.el5.remi
php-cli-5.3.6-4.el5.remi
php-common-5.3.6-4.el5.remi
php-gd-5.3.6-4.el5.remi
php-imap-5.3.6-4.el5.remi
php-mbstring-5.3.6-4.el5.remi
php-mcrypt-5.3.6-4.el5.remi
phpMyAdmin-3.4.0-1.el5.remi
php-mysql-5.3.6-4.el5.remi
php-pdo-5.3.6-4.el5.remi
php-pear-1.9.2-3.el5.remi
phpPgAdmin-5.0.2-1.el5
php-pgsql-5.3.6-4.el5.remi
php-tidy-5.3.6-4.el5.remi
php-xml-5.3.6-4.el5.remi
php-zts-5.3.6-4.el5.remi

# rpm -Va php\*               
S.5....T  c /etc/php.ini
S.5....T  c /etc/phpPgAdmin/config.inc.php
S.5....T  c /etc/phpMyAdmin/config.inc.php

# php -v                         
PHP 5.3.6 (cli) (built: May 16 2011 19:18:05)
Copyright (c) 1997-2011 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2011 Zend Technologies

# php -n -v
PHP 5.3.6 (cli) (built: May 16 2011 19:18:05)
Copyright (c) 1997-2011 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2011 Zend Technologies

Re: PHP 5.3.6-4 builds broken

This could be simply related to Apache itself. We just noticed that httpd was also updated (somehow we missed that). the other servers have httpd-2.2.3-43.el5.centos.3, but this problematic one is running:

# rpm -qi httpd
Name        : httpd                        Relocations: (not relocatable)
Version     : 2.2.3                             Vendor: CentOS
Release     : 45.el5.centos.1               Build Date: Wed 04 May 2011 06:54:52 AM EDT
Install Date: Tue 10 May 2011 09:38:12 AM EDT      Build Host: builder10.centos.org
Group       : System Environment/Daemons    Source RPM: httpd-2.2.3-45.el5.centos.1.src.rpm
Size        : 3461512                          License: Apache Software License
Signature   : DSA/SHA1, Wed 04 May 2011 08:31:28 AM EDT, Key ID a8a447dce8562897
URL         : http://httpd.apache.org/
Summary     : Apache HTTP Server
Description :
The Apache HTTP Server is a powerful, efficient, and extensible
web server.


We'll keep digging, but we don't think at this point it has anything to do with your builds. Thanks for checking though.

Re: PHP 5.3.6-4 builds broken

I don't see any problem with php...

except you have altered the php.ini, which is generally a bad idea (I always prefer using php_value, php_flag, ... in an apache configuration file)

What is, now, the content of /var/log/httpd/error_log when you restart the service ?

Desktop: Fedora 33 + rpmfusion + remi-test + remi-dev
Laptop:  Fedora 32 + rpmfusion + remi (SCL only)
Hosting Server: CentOS 8 Stream with EPEL, rpmfusion, remi

Re: PHP 5.3.6-4 builds broken

It has to be the apache update; yet, nothing seems wrong. The error log during start up shows:

---
[Sun May 22 09:50:33 2011] [notice] suEXEC mechanism enabled (wrapper: /usr/sbin/suexec)
[Sun May 22 09:50:33 2011] [info] Init: Seeding PRNG with 256 bytes of entropy
[Sun May 22 09:50:33 2011] [info] Init: Generating temporary RSA private keys (512/1024 bits)
[Sun May 22 09:50:33 2011] [info] Init: Generating temporary DH parameters (512/1024 bits)
[Sun May 22 09:50:33 2011] [info] Init: Initializing (virtual) servers for SSL
[Sun May 22 09:50:33 2011] [info] Server: Apache/2.2.3, Interface: mod_ssl/2.2.3, Library: OpenSSL/0.9.8e-fips-rhel5
[Sun May 22 09:50:33 2011] [notice] Digest: generating secret for digest authentication ...
[Sun May 22 09:50:33 2011] [notice] Digest: done
[Sun May 22 09:50:33 2011] [debug] util_ldap.c(2021): LDAP merging Shared Cache conf: shm=0x2aba51e25960 rmm=0x2aba51e259b8 for VHOST: ourserver.com
[Sun May 22 09:50:33 2011] [debug] util_ldap.c(2021): LDAP merging Shared Cache conf: shm=0x2aba51e25960 rmm=0x2aba51e259b8 for VHOST: ourserver.com
[Sun May 22 09:50:33 2011] [debug] util_ldap.c(2021): LDAP merging Shared Cache conf: shm=0x2aba51e25960 rmm=0x2aba51e259b8 for VHOST: ourserver.com
[Sun May 22 09:50:33 2011] [info] APR LDAP: Built with OpenLDAP LDAP SDK
[Sun May 22 09:50:33 2011] [info] LDAP: SSL support available
[Sun May 22 09:50:33 2011] [info] mod_fcgid: Process manager 26616 started
[Sun May 22 09:50:34 2011] [info] Init: Seeding PRNG with 256 bytes of entropy
[Sun May 22 09:50:34 2011] [info] Init: Generating temporary RSA private keys (512/1024 bits)
[Sun May 22 09:50:34 2011] [info] Init: Generating temporary DH parameters (512/1024 bits)
[Sun May 22 09:50:34 2011] [debug] ssl_scache_shmcb.c(374): shmcb_init allocated 512000 bytes of shared memory
[Sun May 22 09:50:34 2011] [debug] ssl_scache_shmcb.c(554): entered shmcb_init_memory()
[Sun May 22 09:50:34 2011] [debug] ssl_scache_shmcb.c(576): for 512000 bytes, recommending 4265 indexes
[Sun May 22 09:50:34 2011] [debug] ssl_scache_shmcb.c(619): shmcb_init_memory choices follow
[Sun May 22 09:50:34 2011] [debug] ssl_scache_shmcb.c(621): division_mask = 0x1F
[Sun May 22 09:50:34 2011] [debug] ssl_scache_shmcb.c(623): division_offset = 96
[Sun May 22 09:50:34 2011] [debug] ssl_scache_shmcb.c(625): division_size = 15997
[Sun May 22 09:50:34 2011] [debug] ssl_scache_shmcb.c(627): queue_size = 2136
[Sun May 22 09:50:34 2011] [debug] ssl_scache_shmcb.c(629): index_num = 133
[Sun May 22 09:50:34 2011] [debug] ssl_scache_shmcb.c(631): index_offset = 8
[Sun May 22 09:50:34 2011] [debug] ssl_scache_shmcb.c(633): index_size = 16
[Sun May 22 09:50:34 2011] [debug] ssl_scache_shmcb.c(635): cache_data_offset = 8
[Sun May 22 09:50:34 2011] [debug] ssl_scache_shmcb.c(637): cache_data_size = 13853
[Sun May 22 09:50:34 2011] [debug] ssl_scache_shmcb.c(650): leaving shmcb_init_memory()
[Sun May 22 09:50:34 2011] [info] Shared memory session cache initialised
[Sun May 22 09:50:34 2011] [info] Init: Initializing (virtual) servers for SSL
[Sun May 22 09:50:34 2011] [info] Server: Apache/2.2.3, Interface: mod_ssl/2.2.3, Library: OpenSSL/0.9.8e-fips-rhel5
[Sun May 22 09:50:34 2011] [debug] proxy_util.c(1854): proxy: grabbed scoreboard slot 0 in child 26622 for worker proxy:reverse
[Sun May 22 09:50:34 2011] [debug] proxy_util.c(1967): proxy: initialized single connection worker 0 in child 26622 for (*)
[Sun May 22 09:50:34 2011] [debug] proxy_util.c(1854): proxy: grabbed scoreboard slot 0 in child 26623 for worker proxy:reverse
[Sun May 22 09:50:34 2011] [debug] proxy_util.c(1873): proxy: worker proxy:reverse already initialized
[Sun May 22 09:50:34 2011] [debug] proxy_util.c(1967): proxy: initialized single connection worker 0 in child 26623 for (*)
[Sun May 22 09:50:34 2011] [debug] proxy_util.c(1854): proxy: grabbed scoreboard slot 0 in child 27648 for worker proxy:reverse
[Sun May 22 09:50:34 2011] [debug] proxy_util.c(1873): proxy: worker proxy:reverse already initialized
[Sun May 22 09:50:34 2011] [debug] proxy_util.c(1967): proxy: initialized single connection worker 0 in child 27648 for (*)
[Sun May 22 09:50:34 2011] [debug] proxy_util.c(1854): proxy: grabbed scoreboard slot 0 in child 27649 for worker proxy:reverse
[Sun May 22 09:50:34 2011] [debug] proxy_util.c(1873): proxy: worker proxy:reverse already initialized
[Sun May 22 09:50:34 2011] [debug] proxy_util.c(1967): proxy: initialized single connection worker 0 in child 27649 for (*)
[Sun May 22 09:50:34 2011] [debug] proxy_util.c(1854): proxy: grabbed scoreboard slot 0 in child 27650 for worker proxy:reverse
[Sun May 22 09:50:34 2011] [debug] proxy_util.c(1873): proxy: worker proxy:reverse already initialized
[Sun May 22 09:50:34 2011] [debug] proxy_util.c(1967): proxy: initialized single connection worker 0 in child 27650 for (*)
[Sun May 22 09:50:34 2011] [debug] proxy_util.c(1854): proxy: grabbed scoreboard slot 0 in child 27652 for worker proxy:reverse
[Sun May 22 09:50:34 2011] [debug] proxy_util.c(1873): proxy: worker proxy:reverse already initialized
[Sun May 22 09:50:34 2011] [debug] proxy_util.c(1967): proxy: initialized single connection worker 0 in child 27652 for (*)
[Sun May 22 09:50:34 2011] [debug] proxy_util.c(1854): proxy: grabbed scoreboard slot 0 in child 27653 for worker proxy:reverse
[Sun May 22 09:50:34 2011] [debug] proxy_util.c(1873): proxy: worker proxy:reverse already initialized
[Sun May 22 09:50:34 2011] [debug] proxy_util.c(1967): proxy: initialized single connection worker 0 in child 27653 for (*)
[Sun May 22 09:50:34 2011] [debug] proxy_util.c(1854): proxy: grabbed scoreboard slot 0 in child 27654 for worker proxy:reverse
[Sun May 22 09:50:34 2011] [debug] proxy_util.c(1873): proxy: worker proxy:reverse already initialized
[Sun May 22 09:50:34 2011] [debug] proxy_util.c(1967): proxy: initialized single connection worker 0 in child 27654 for (*)
[Sun May 22 09:50:34 2011] [notice] Apache configured -- resuming normal operations
[Sun May 22 09:50:34 2011] [info] Server built: May  4 2011 06:51:15
[Sun May 22 09:50:34 2011] [debug] prefork.c(991): AcceptMutex: sysvsem (default: sysvsem)
---

We see 10 httpd process start up and all seems fine. As soon as a request is made to the server (to nothing more than a basic index.html file), one of the httpd threads immediately starts consuming ~25% of the CPU and driving load to 4+ and keeping it around 2.8+. The request never completes successfully.

Re: PHP 5.3.6-4 builds broken

Hi all,

Have been seeing the same thing with both 5.3.6-4 and now with 5.3.7-1 on CentOS 5.6 (with httpd-2.2.3-45.el5.centos.1, prefork) and I don't think it's the Apache.

We have around 30 boxes running our PHP code with 5.3.6-3 and we don't have any issues, boxes running 5.3.6-4 or newer segfault. I've not yet been able to isolate which of our scripts causes the behaviour but I'm going to continue to look.

Our Apaches that work look like this:

[root@api13 ~]# rpm -qa | grep remi
php-cli-5.3.6-3.el5.remi
php-mcrypt-5.3.6-3.el5.remi
php-pear-1.9.4-1.el5.remi
remi-release-5-8.el5.remi
memcached-1.4.5-2.el5.remi
mysql-libs-5.5.15-1.el5.remi
libmemcached-0.49-1.el5.remi
mysql-server-5.5.15-1.el5.remi
php-common-5.3.6-3.el5.remi
php-pdo-5.3.6-3.el5.remi
php-5.3.6-3.el5.remi
php-mbstring-5.3.6-3.el5.remi
php-xml-5.3.6-3.el5.remi
php-pecl-memcache-3.0.6-1.el5.remi
sqlite2-2.8.17-2.el5.remi
mysqlclient15-5.0.67-1.el5.remi
mysql-5.5.15-1.el5.remi
php-mysql-5.3.6-3.el5.remi
php-gd-5.3.6-3.el5.remi
php-pecl-mongo-1.0.10-4.el5.remi
[root@api13 ~]# 

[root@api13 ~]# rpm -qa | grep httpd
httpd-2.2.3-45.el5.centos.1
[root@api13 ~]# 

Ones that don't look like this (this is 5.3.7-1 but the same is true for 5.3.6-4)

[root@api14 conf]# rpm -qa | grep remi
remi-release-5-8.el5.remi
php-cli-5.3.7-1.el5.remi
php-pdo-5.3.7-1.el5.remi
php-pecl-mongo-1.2.1-1.el5.remi
mysql-5.5.15-1.el5.remi
mysql-server-5.5.15-1.el5.remi
php-common-5.3.7-1.el5.remi
php-pear-1.9.4-1.el5.remi
php-pecl-memcache-3.0.6-1.el5.remi
php-5.3.7-1.el5.remi
php-gd-5.3.7-1.el5.remi
php-mysql-5.3.7-1.el5.remi
php-mbstring-5.3.7-1.el5.remi
sqlite2-2.8.17-2.el5.remi
mysqlclient15-5.0.67-1.el5.remi
memcached-1.4.5-2.el5.remi
mysql-libs-5.5.15-1.el5.remi
php-mcrypt-5.3.7-1.el5.remi
php-xml-5.3.7-1.el5.remi
[root@api14 conf]# 

[root@api14 conf]# rpm -qa | grep httpd
httpd-2.2.3-45.el5.centos.1
[root@api14 conf]# 

For what it's worth, the failure isn't very helpful and looks like this:

[Fri Aug 19 12:31:12 2011] [notice] child pid 4191 exit signal Segmentation fault (11)
[Fri Aug 19 12:31:12 2011] [notice] child pid 4241 exit signal Segmentation fault (11)
[Fri Aug 19 12:31:12 2011] [notice] child pid 4245 exit signal Segmentation fault (11)
[Fri Aug 19 12:31:12 2011] [notice] child pid 4250 exit signal Segmentation fault (11)
[Fri Aug 19 12:31:12 2011] [notice] child pid 4270 exit signal Segmentation fault (11)

These servers exclusively server APIs only so it's going to be an issue with the PHP itself or the MySQL, Mongo or memcached drivers. I'm going to continue to investigate but something changed between .6-3 and .6-4, and it exists as well in .7-1.

Cheers,

Steph

Re: PHP 5.3.6-4 builds broken

Seems linked to https://bugzilla.redhat.com/694630

Desktop: Fedora 33 + rpmfusion + remi-test + remi-dev
Laptop:  Fedora 32 + rpmfusion + remi (SCL only)
Hosting Server: CentOS 8 Stream with EPEL, rpmfusion, remi

Re: PHP 5.3.6-4 builds broken

Can you please test new mongo version 1.2.3, in remi-test (i386 and x86_64) ?

This new version should, according to upstream, fixes some segfault cases (I don't use this extension, so can't test)

Desktop: Fedora 33 + rpmfusion + remi-test + remi-dev
Laptop:  Fedora 32 + rpmfusion + remi (SCL only)
Hosting Server: CentOS 8 Stream with EPEL, rpmfusion, remi

Re: PHP 5.3.6-4 builds broken

Hi Remi, thanks for the quick reply.

If we're waiting for upstream to fix is there any possibility to have 5.3.6-3 made available again? With the release of 5.3.7-1 the older version went away and I guess you're only keeping the current and previous releases around.

Cheers,

Steph

Re: PHP 5.3.6-4 builds broken

Remi wrote:

Can you please test new mongo version 1.2.3, in remi-test (i386 and x86_64) ?

This new version should, according to upstream, fixes some segfault cases (I don't use this extension, so can't test)

Sadly 1.2.3-1 doesn't seem to fix it for us.

Re: PHP 5.3.6-4 builds broken

Change between -3 and -4 only concerns the mssql extension.

So I don't think this is this update which breaks your configuration.
Try to revert mongo to 1.0.10 (still in the repo)

Desktop: Fedora 33 + rpmfusion + remi-test + remi-dev
Laptop:  Fedora 32 + rpmfusion + remi (SCL only)
Hosting Server: CentOS 8 Stream with EPEL, rpmfusion, remi

Re: PHP 5.3.6-4 builds broken

Remi wrote:

Change between -3 and -4 only concerns the mssql extension.

So I don't think this is this update which breaks your configuration.
Try to revert mongo to 1.0.10 (still in the repo)

Aha! php-pecl-mongo-1.0.10-4.el5.remi works! What on earth is going on then with the newer versions?!

Re: PHP 5.3.6-4 builds broken

I think there is a link between client (php-pecl-mongo) and server (mongodb) versions....
But I don't find any sources about this

Desktop: Fedora 33 + rpmfusion + remi-test + remi-dev
Laptop:  Fedora 32 + rpmfusion + remi (SCL only)
Hosting Server: CentOS 8 Stream with EPEL, rpmfusion, remi

Re: PHP 5.3.6-4 builds broken

Remi wrote:

I think there is a link between client (php-pecl-mongo) and server (mongodb) versions....
But I don't find any sources about this

It's entirely possible but I'd find it a bit odd. The initial release date for 1.0.10 was September last year but we're running the latest official 10gen Mongo RPMs (mongo-10gen-1.8.2-mongodb_1, mongo-10gen-server-1.8.2-mongodb_1). I will write to the mailing list and see if Kristina (the maintainer) has any insight.

Cheers,

Steph