PHP 5.3.3 (cli) started to output error: PHP Warning: PHP Startup: Unable to load dynamic library '/usr/lib/php/modules/module

14 posts / 0 new
Last post
#1 Fri, 03/22/2013 - 16:03
yngens

PHP 5.3.3 (cli) started to output error: PHP Warning: PHP Startup: Unable to load dynamic library '/usr/lib/php/modules/module

Subj. The complete error message is follows:

PHP Warning:  PHP Startup: Unable to load dynamic library '/usr/lib/php/modules/module.so' - /usr/lib/php/modules/module.so: cannot open shared object file: No such file or directory in Unknown on line 0

I know it is not of Virtualmin or Webmin's issue, however I don't know where to report it, since as you can see on https://bugs.php.net/report.php, they are accepting error reports only starting with PHP version 5.3.23. It is clearly stated there: "Earlier? Upgrade first!"

However, I always try what comes with Virtualmin/Webmin repositories and probably Virtualmin/Webmin follows whatever versions are officially supported by the operating system vendors. Mine is currently CentOS 6.4 and I believe this issue started after upgrade from 6.3 to 6.4. Should I report this issue with CentOS or RHL or Fedora?

I tried to google the error, but to my surprise there is no single result for "module.so" or "module.ini" keywords, so apparently this is very fresh error in PHP. There are simply no such files in my system and no any single reference to them in the net.

Fri, 03/22/2013 - 22:44
andreychek

Howdy,

So you're saying you get that error when running the "php" command on the command line? And that happens for any user, not just one in particular?

If that's the case, you may want to look at the various .ini files in /etc/php.d to see if any contain something that's telling PHP to try to load that module.

You may also want to take a look at /etc/php.ini to see if that shows up in there.

-Eric

Fri, 03/22/2013 - 23:40 (Reply to #2)
yngens

Hi Eric,

Yes, 'php -v' command is outputting this error:

root@ns1:/root#
php -v
PHP Warning:  PHP Startup: Unable to load dynamic library '/usr/lib/php/modules/module.so' - /usr/lib/php/modules/module.so: cannot open shared object file: No such file or directory in Unknown on line 0
PHP 5.3.3 (cli) (built: Feb 22 2013 02:37:06)
Copyright (c) 1997-2010 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2010 Zend Technologies

My /etc/php.d directory contains:

root@ns1:/etc/php.d#
l
total 116
-rw-r--r-- 1 root root  96 Jan  4 09:09 apc.ini
-rw-r--r-- 1 root root  49 Feb 22 04:42 curl.ini
-rw-r--r-- 1 root root  47 Feb 22 04:42 dom.ini
-rw-r--r-- 1 root root  57 Feb 22 04:42 fileinfo.ini
-rw-r--r-- 1 root root  45 Feb 22 04:42 gd.ini
-rw-r--r-- 1 root root  49 Feb 22 04:42 imap.ini
-rw-r--r-- 1 root root  49 Feb 22 04:42 json.ini
-rw-r--r-- 1 root root  57 Feb 22 04:42 mbstring.ini
-rw-r--r-- 1 root root  53 Feb 19 17:06 mcrypt.ini
-rw-r--r-- 1 root root 297 Jan 29  2011 memcached.ini
-rw-r--r-- 1 root root  53 Feb 22 04:42 mysqli.ini
-rw-r--r-- 1 root root  51 Feb 22 04:42 mysql.ini
-rw-r--r-- 1 root root  49 Feb 22 04:42 odbc.ini
-rw-r--r-- 1 root root  47 Feb 22 04:42 pdo.ini
-rw-r--r-- 1 root root  59 Feb 22 04:42 pdo_mysql.ini
-rw-r--r-- 1 root root  57 Feb 22 04:42 pdo_odbc.ini
-rw-r--r-- 1 root root  59 Feb 22 04:42 pdo_pgsql.ini
-rw-r--r-- 1 root root  61 Feb 22 04:42 pdo_sqlite.ini
-rw-r--r-- 1 root root  51 Feb 22 04:42 pgsql.ini
-rw-r--r-- 1 root root  49 Feb 22 04:42 phar.ini
-rw-r--r-- 1 root root  49 Feb 22 04:42 snmp.ini
-rw-r--r-- 1 root root  55 Feb 22 04:42 sqlite3.ini
-rw-r--r-- 1 root root  28 Dec 17 19:41 uploadprogress.ini
-rw-r--r-- 1 root root  49 Feb 22 04:42 wddx.ini
-rw-r--r-- 1 root root  59 Feb 22 04:42 xmlreader.ini
-rw-r--r-- 1 root root  53 Feb 22 04:42 xmlrpc.ini
-rw-r--r-- 1 root root  59 Feb 22 04:42 xmlwriter.ini
-rw-r--r-- 1 root root  47 Feb 22 04:42 xsl.ini
-rw-r--r-- 1 root root  47 Feb 22 04:42 zip.ini

I also didn't touch php.ini file, but nevertheless looking its content also doesn't give anything suspicious. And this is happening in all Virtualmin VPS' under Cloudmin GPL. So I do believe one of the last updates or upgrades has changed something.

Sat, 03/23/2013 - 02:08 (Reply to #3)
red6

Don't know why but...

grep sqlite *.ini in the directory /etc/php.ini

reveals:

pdo_sqlite.ini:; Enable pdo_sqlite extension module pdo_sqlite.ini:extension=pdo_sqlite.so sqlite3.ini:; Enable sqlite3 extension module sqlite3.ini:extension=sqlite3.so

Commenting out the 2nd line in pdo_sqlite.ini and the 2nd line in sqlite.ini and run php -v to get

PHP 5.3.3 (cli) (built: Feb 22 2013 02:51:11) Copyright (c) 1997-2010 The PHP Group Zend Engine v2.3.0, Copyright (c) 1998-2010 Zend Technologies

I still get the warning as described at the top of this thread.

Sat, 03/23/2013 - 01:56 (Reply to #4)
red6

I too started getting the same error. I upgraded 2 of my CentOs 6.3 machines to 6.4 and the problem started.

I have no file on my system called modules.so. (That would explain the error I guess).

But I have no trace of a reference to this file in any of the php ini files.

But here is something interesting... If I do grep -r "modules.so" . from the current working directory of /usr I get...

Binary file ./tmp/yum-mark-x5G0as/x86_64/6/epel/fb7e7875f12236f21632bcce4679c401b1b8645023c57162e7d9b584f624ae27-primary.sqlite matches Binary file ./tmp/yum-mark-x5G0as/x86_64/6/base/5dc95bc0e6520499d90c6ffbad197c9031b13b19f754818dbdb11f31249cb4f6-primary.sqlite matches

Maybe a problem with mysql lite ? Not that I am running sqlite.

Hmmmm...?

Sun, 03/24/2013 - 01:02 (Reply to #5)
red6

Try 'yum downgrade php-mcrypt'.

Fixes an 'mcrypt' problem and the php 'module.so' warning/error goes away.

Only discovered this today when I found the mcrypt extension was busted in latest pkg update.

Lat time I updrade to anything new.

Don't break it if it ain't fixed.

Sun, 03/24/2013 - 03:38 (Reply to #6)
yngens

But will the system ask for upgrade again after this downgrade? I really would like to go by what is officially supported by Virtualmin/Webmin. I wonder does Jamie have anything to say about this issue? What is recommended way to address the issue?

Sun, 03/24/2013 - 23:26 (Reply to #7)
red6

My systems are showing the package as available for upgrading but I am going to de-select the mcrypt package in Webmin until I see evidence of a fix.

Mon, 03/25/2013 - 08:30
andreychek

Howdy,

So far, you're the only two to report this issue, but it's quite unusual!

Am I correct in remembering that php-mcrypt isn't provided by CentOS/RHEL, but instead comes from a third party repo?

If that's true, how did you go about installing the php-mcrypt module?

I believe that one is provided by EPEL... which may just mean you need to grab an update for that module from the EPEL repository.

-Eric

Mon, 03/25/2013 - 14:51 (Reply to #9)
yngens

Eric, thanks, your suggestion made me to conduct the following small research.

One of my VPS servers didn't output the error in subject, so I compared and found out 'php-mcrypt' on healthy server was installed from Atomic repository, but on all others from Rpmforge. So I have changed yum priorities and tried to re-install the package, however, unfortunately, stuck at the following conflict:

root@ns1:/etc/yum.repos.d#
yum install php-mcrypt
Loaded plugins: fastestmirror, priorities
Loading mirror speeds from cached hostfile
* atomic: www2.atomicorp.com
* base: mirror.pac-12.org
* epel: mirrors.kernel.org
* rpmforge: mirror.hmc.edu
545 packages excluded due to repository priority protections
Setting up Install Process
Resolving Dependencies
--> Running transaction check
---> Package php-mcrypt.i686 0:5.3.23-16.el6.art will be installed
--> Processing Dependency: php-common(x86-32) = 5.3.23-16.el6.art for package: php-mcrypt-5.3.23-16.el6.art.i686
--> Finished Dependency Resolution
Error: Package: php-mcrypt-5.3.23-16.el6.art.i686 (atomic)
           Requires: php-common(x86-32) = 5.3.23-16.el6.art
           Installed: php-common-5.3.3-22.el6.i686 (@base)
               php-common(x86-32) = 5.3.3-22.el6
You could try using --skip-broken to work around the problem
You could try running: rpm -Va --nofiles --nodigest

And here is the info for 'php-common' package in the healthy system:

root@my:/etc/yum.repos.d#
yum info php-common
Loaded plugins: fastestmirror, priorities
Loading mirror speeds from cached hostfile
* base: mirrors.kernel.org
* epel: mirrors.kernel.org
* rpmforge: mirror.hmc.edu
183 packages excluded due to repository priority protections
Installed Packages
Name        : php-common
Arch        : i686
Version     : 5.3.20
Release     : 13.el6.art
Size        : 6.3 M
Repo        : installed
From repo   : atomic
Summary     : Common files for PHP
URL         : http://www.php.net/
License     : PHP
Description : The php-common package contains files used by both the php
            : package and the php-cli package.

Here is info for php-common an a faulty system:

root@ns1:/etc/yum.repos.d#
yum info php-common
Loaded plugins: fastestmirror, priorities
Loading mirror speeds from cached hostfile
* atomic: www2.atomicorp.com
* base: mirror.pac-12.org
* epel: mirrors.kernel.org
* rpmforge: mirror.hmc.edu
545 packages excluded due to repository priority protections
Installed Packages
Name        : php-common
Arch        : i686
Version     : 5.3.3
Release     : 22.el6
Size        : 2.9 M
Repo        : installed
From repo   : base
Summary     : Common files for PHP
URL         : http://www.php.net/
License     : PHP
Description : The php-common package contains files used by both the php
            : package and the php-cli package.

Both systems are Virtualmin, so I really don't know how they managed to get php-common from two different repositories. Or this package is not included in default LAMP stack that is installed by Virtualmin installation script? Is it safe to remove and install again 'php-common' package on a running system with Virtualmin or it can break it?

Fri, 03/29/2013 - 10:26 (Reply to #10)
red6

Your are correct. Just checked. php mcrypt does come from epel in my case.

So not sure where that leaves me but at least I am up and running with the 'downgrade' I mentioned above.

Fri, 05/17/2013 - 05:22
yngens

Ok, guys, this problem is dealt surprisingly much easier. Just edit /etc/php.d/mcrypt.ini and change

extension=module.so

to

extension=mcrypt.so
Mon, 07/29/2013 - 15:17
JamesSimpson

The above doesnt work, as we now get the following error:

PHP Warning: Module 'mcrypt' already loaded in Unknown on line 0

Sat, 08/03/2013 - 01:27 (Reply to #13)
yngens

James,

You either need to remove mcrypt.ini from /etc/php.d directory or edit '/etc/php.ini', find 'extension=mcrypt.so', remove, save the file and restart Apache.

Topic locked