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

Virtualmin
1

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.

2

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

3

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.

4

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…?

5

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 © 1997-2010 The PHP Group
Zend Engine v2.3.0, Copyright © 1998-2010 Zend Technologies

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

6

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.

7

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?

8

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.

9

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

10

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?

11

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.

12

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
13

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

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

14

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.