Unable to load dynamic library '/usr/lib/php/20151012/mysql.so'

[hostingnuggets]

Affected Puppet, Ruby, OS and module versions/distributions

• Puppet: 4.8.2
• Ruby: 2.3.3
• Distribution: Debian 9
• Module version: 4.0.0

How to reproduce (e.g Puppet code you use)

Manifest:

class { '::php': }

Hiera:

php::globals::php_version: '7.0'
php::composer: false
php::dev: false
php::manage_repos: false
php::pear: false
php::settings:
  'PHP/max_execution_time': '60'
  'PHP/max_input_time': '240'
  'PHP/memory_limit': '128M'
  'PHP/post_max_size': '32M'
  'PHP/upload_max_filesize': '32M'
  'Date/date.timezone': 'Europe/Berlin'
php::fpm::pools:
  www:
    listen: '/var/run/php-fpm.sock'
    listen_group: 'www-data'
php::extensions:
  curl: {}
  gd: {}
  intl: {}
  mcrypt: {}
  mysql: {}
  pgsql: {}
  pspell: {}
  tidy: {}
  xsl: {}

What are you seeing

A file /etc/php/7.0/mods-available/mysql.ini with the following content gets created by the puppet module:

extension = mysql.so

but on Debian 9 there is no mysql.so file only a pdo_mysql.so and mysql.i.so.

What behaviour did you expect instead

I guess the file /etc/php/7.0/mods-available/mysql.ini should not be created on Debian 9 as mysql.so is not available.

Output log

Aug 1 16:09:00 vps sessionclean[29576]: PHP Warning: PHP Startup: Unable to load dynamic library '/usr/lib/php/20151012/mysql.so' - /usr/lib/php/20151012/mysql.so: cannot open shared object file: No such file or directory in Unknown on line 0

Any additional information you'd like to impart

[hboetes]

The mysql package installs these so files, but not mysql.so:

mysqli.so
mysqlnd.so
pdo_mysql.so

But the php puppet module creates its own mysql.ini in ./mods-available. This needs to be disabled for mysql.

[Yggdrasil]

This still happens with module 5.1.0 (on Ubuntu 14.04).

Have any of you implemented a workaround to get rid of the constant errors?

[hostingnuggets]

@Yggdrasil yeah just comment out mysql: {} from your Hiera YAML file when installed but that's really an ugly workaround. It looks like they don't care about Debian.

[leoserra]

Hi, I had the same issue. I solved this using parameter so_name with value mysqlnd.

Using Hiera YAML:

php::extensions:
  mysql: { so_name: 'mysqlnd' }

[Yggdrasil]

@leoserra That's similar to what we did. I solved it by removing the extension=mysql.so line from mysql.ini, via Hiera:

php::extensions:
  mysql: { 'settings': { 'extension': } }

It's still a hack but one of the less ugly ones IMHO.

[jeff1evesque]

Using centos7x, I needed to define extensions with so_name, using the same syntax @leoserra indicated. Otherwise, the /etc/php.d/[MY-EXTENSION].ini was created. However, /usr/lib64/php/modules/[MY-EXTENSION].so was never created. Thank you, for these comments.

[kabircse]

What is the solution ?

[mpdude]

Here is what works for me™ on Ubuntu 17.10.

The problem is that we have a single package, php7.1-mysql, that has to be installed. This module provides three .so files, namely mysqli.so, mysqlnd.so and pdo_mysql.so. For each of those, a corresponsing .ini file exists in /usr/share/php7.1-mysql/mysql/.

This Puppet module seems to be unable to handle this special case as it assumes a one-to-one relationship between Packages that need to be installed, contained .so files/PHP extensions and .ini files used to configure those.

So, the following config

    class { '::php::globals':
      php_version => '7.1',
    } -> class { '::php':
        manage_repos => false,
        ...
        extensions   => {
            "mysql" => {
                'so_name' => 'mysqli'
            },
        }
    }

... will install php7.1-mysql unless /usr/sbin/phpquery -v 7.1 -s cli -m mysqli reports that the mysqli extension is active. It otherwise leaves configuration alone, that is, keeps the .ini files provided by the package.

YMMV: This will most probably not be able to clean up after you if you disable one of the contained extensions. I haven't tried whether or how this supports additional config necessary for the mysql modules.

[Yggdrasil]

@mpdude's config partially worked for us. It maintained the mysqli config but kept removing the mysqlnd en pdo_mysql config files.

I've now found a setup that works well for us:

(In Hiera yaml format)

php::globals::php_version: '7.2'
php::extensions:
  mysql: {
    'multifile_settings': true,
    'settings': {
      'mysqli': { },
      'mysqlnd': { },
      'pdo_mysql': { }
    }
  }

This uses the multifile_settings parameter, which was introduced in module v6.0.0, originally to support RedHat Software Collections (SCL), but works for Ubuntu as well.

I've not tested it extensively, but it seems to work on our Ubuntu 14.04 nodes. It installs the php7.2-mysql package but tells the module that it contains and should manage three config files that are named differently from the package.

It also still allows all settings to be defined for each of the three extensions.

[bit-herder]

thanks, your earlier hack made the warning go away but this is nice to have, thanks much!

[bastelfreak]

@Yggdrasil could you provide a PR that add the snippet to our README.md? if you like you can also extend our acceptance tests with it: https://github.com/voxpupuli/puppet-php/blob/master/spec/acceptance/php_spec.rb

[juchems]

@bastelfreak - I have been following this issue since about August 10th and was hoping something would happen 👍

However, can I get the non-yaml syntax as well?

The provided syntax for omitting certain configurations form the .ini files is in Hiera format as well, and I would greatly appreciate direct syntax for that.

FWIW I am experiencing similar errors with ps.so, seclib.so, sqllite.so and tcpdf.so and I am hoping this multifile configuration allow me to resolve some/all of them. Thank you!

[bastelfreak]

@juchems which puppet syntax did you try? could you provide that in a PR as an enhancement to our acceptance tests?

[juchems]

@bastelfreak I am not sure what adding a PR for nonfunctional code would do.

I am pasting the relevant section here that doesn't cause syntax errors and seems to reflect how the Hiera spec works above.

class { '::php':
  manage_repos => false,
    extensions => {
      curl     => {},
      gd       => {},
      imap     => {},
      mcrypt   => {},
      pspell   => {},
      recode   => {},
      snmp     => {},
      tidy     => {},
      xmlrpc   => {},
      xsl      => {},
      zip      => {},
      mbstring => {},
      tcpdf    => { package_prefix  => 'php-', },
      seclib   => { package_prefix  => 'php-', },
      mysql    => {
        package_prefix     => 'php7.1-',
        multifile_settings => true,
        settings           => {
          msyqli    => {},
          mysqlnd   => {},
          pdo_mysql => {},
          },
      },

I am still getting the following errors when running any PHP command from the console.

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

[juchems]

Ultimately, I solved my errors by having the module do less extension configuration.

Noticeably, in extension.pp, we get a hard coded pass on doing all the extra stuff if the source is Pear. If this was more abstracted, it could be useful for other packages that have their own configurations that don't include ini files but are not sourced from Pear. In my case this was the seclib and tcpdf extensions. In the end, I used this for the mysql extension as well.

Line 104 in extension.pp

  # PEAR packages don't require any further configuration, they just need to "be there".
  if $provider != 'pear' {
    if $extended_config_required == '1' {

The first "if" is provided, the second I created.

Added it to the variables for the pp file:

Variant[String, Array[String]] $compiler_packages = $php::params::compiler_packages,
  Php::InstallOptions $install_options              = undef,
  String         $extended_config_required         = '1',

The I just went ahead and defined in each extension:

 fpm_global_pool_settings => {listen => '/run/php/php7.2-fpm.sock'},
  manage_repos => false,
    extensions => {
      curl     => {},
      gd       => {},
      imap     => {},
      #mcrypt   => {},
      pspell   => {},
      recode   => {},
      snmp     => {},
      tidy     => {},
      xmlrpc   => {},
      xsl      => {},
      zip      => {},
      mbstring => {},
      tcpdf    => { package_prefix  => 'php-', extended_config_required => '0'},
      seclib   => { package_prefix  => 'php-', extended_config_required => '0'},
      bcmath   => {},
      intl     => {},
      mysql    => {
        package_prefix           => 'php7.2-',
        multifile_settings       => true,
        extended_config_required => '0',
        settings                 => {
          msyqli    => {},
          mysqlnd   => {},
          pdo_mysql => {},
          },
      },
    },

My problems were solved. There is some loss of functionality in that there is some lost control via the Puppet module, but the trade off was worth it because I also resolved this log filling issue that occurred when I let the Puppet module more completely maintain the mysql extension:

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

because the apt package evidently drops the this file in mods-available folder with this information:

; configuration for php mysql module
; priority=10
extension=mysqlnd.so

Without that second line, the default priority is 20. The Puppet module was overwriting this ini file in it's zeal and leaving me with a duplicate symlink (both 10-mysqlnd and 20-mysqlnd) that I needed to delete manually. The package should know the priority better than this Puppet module so I wanted to preserve it but adding this line to the Puppet Module created/maintained ini file:

; priority=10

with the tools provided by the module proved more than I could figure out today.