Hey there, I got the same issue.

Problem was in this file /etc/cl.selector/defaults.cfg

The modules lines for a reason didn't contains any of the "mysql' extensions.

Also, I had to run selectorctl "--enable-user-extensions" command on all users with the correct version and extensions.

Was not a good day.

Hello,

Please submit a ticket to https://cloudlinux.zendesk.com, our techs will check the issue in place.

Hey there, I got the same issue.

Problem was in this file /etc/cl.selector/defaults.cfg

The modules lines for a reason didn't contains any of the "mysql' extensions.

Also, I had to run selectorctl "--enable-user-extensions" command on all users with the correct version and extensions.

Was not a good day.

I don't think that was the same issue for me. All sites were fine before I ran the /usr/bin/switch_mod_lsapi --setup
script and converting native apache to use lsapi with... switch_mod_lsapi --build-native-lsphp.

It was only after this that the problem occurred.

I think the issue is related to how lsapi determines the MySQL socket. I have read that in some cases it seems using 127.0.0.1 instead of localhost in the config for your application will resolve this. I didn't have time to test it because I was in a panic to switch everything back again.

In my.cnf I have socket=/var/lib/mysql/mysql.sock
In the php.ini files generated by alt-php the mysql and mysqli socket directives are empty, meaning the defaults are in place, but the default is /var/lib/mysql/mysql.sock anyway - so that shouldn't be a problem
I notice there is a symlink mysql.sock in /tmp pointing also to /var/lib/mysql/mysql.sock
The /etc/hosts file is correctly configured

Still no idea really.

Testing again...

I ran...
/usr/bin/switch_mod_lsapi --setup
/usr/bin/switch_mod_lsapi --enable-global

I decided not to run...
switch_mod_lsapi --build-native-lsphp

And everything seems fine. Most of our users are running alt-php versions and their sites test out OK.

So in this case it would seem running the switch_mod_lsapi --build-native-lsphp script was the issue. Rebuilding Apache (EasyApache3) with native lsphp support seems to break Mysql connections from PHP. I would guess it is socket related as I mentioned above - but I'm not going to test that again!

Will be switching to EA4 soon anyway so I hope this will not be a problem when we do.

"switch_mod_lsapi --build-native-lsphp" this command actually detect the version of native php and build needed sources according to installed php.

Have you checked whether additional .ini files (alt_php.ini) were loaded after you have issues this command?

On EA4 servers "--build-native-lsphp" is deprecated, because lsphp binaries are delivered with ea-phpXX packages.

"switch_mod_lsapi --build-native-lsphp" this command actually detect the version of native php and build needed sources according to installed php.

Yes, I understand that. I wanted to switch the native PHP version to lsapi - so that's why I ran your script.

Have you checked whether additional .ini files (alt_php.ini) were loaded after you have issues this command?

What do you mean? What additional files and where would they be located? Your documentation doesn't mention anything about any additional ini files.

In phpinfo output, you should see "Additional .ini files parsed" filed with individual php.ini files.
These files contain PHP extension settings and extension directives selected by a customer. More information you can find in our documentation:
http://docs.cloudlinux.com/index.html?individual_php_ini_files.html

Please submit a ticket to https://cloudlinux.zendesk.com, if this problem reappears.

In phpinfo output, you should see "Additional .ini files parsed" filed with individual php.ini files.
These files contain PHP extension settings and extension directives selected by a customer. More information you can find in our documentation:
http://docs.cloudlinux.com/index.html?individual_php_ini_files.html

Please submit a ticket to https://cloudlinux.zendesk.com, if this problem reappears.

This is not relevant. We don't allow customers to change the modules, this is disabled in lve settings.

What I have noticed quiet specifically is that the native PHP is affected by running

/usr/bin/switch_mod_lsapi --setup
/usr/bin/switch_mod_lsapi --enable-global

Native PHP should not be influenced by this change - however, after running the above, some customers using native PHP cannot connect to MySQL - until we recompile Apache and native PHP again.

Note: We are not running the switch_mod_lsapi --build-native-lsphp script. Only the above two.

When running easyapache 3 with PHP compiled with the suphp handler and converting alt-php to use lsapi with the above commands, this is causing some problem with the native PHP version and users have issues connecting to MySQL.

To fix this issue, it is necessary to recompile Apache / native PHP again - which resolves the problem. I don't know why this happens - but I performed the above on 21 servers this weekend and needed to recompile Apache on all of them afterwards.

I would like to ask one further question....

We are running EA3 with native PHP using suPHP and we are running alt-php with your php selector, now with lsapi. What will happen when we switch to EA4? I want to run EA4 with native PHP 7 and alt-php versions with lsapi.

Once I have recompiled Apache and native PHP with EA4 - is there anything I will need to do to make sure alt-php is running correctly and with lsapi?

Thank you for your time.

As mentioned above, I'm currently using EA3 and have configured alt-php wih lsapi.

If I rebuild Apache with EA4, can you please tell me - will the current alt-php lsapi situation continue to work as normal? - or will I need to do anything else to make sure it is configured correctly after the EA4 rebuild?

Chris,

There is no such action as "recompile" in EA4. All necessary components like Apache, its modules, PHP and PHP extensions are installed as RPM packages.

If you are planning to migrate to EA4, please refer to our doc section first: http://docs.cloudlinux.com/index.html?cpanel_easyapache_4.html

After the conversion, everything should work fine without any additional actions.