Minor PHP error message when creating a new VS

hello - i am getting this message when creating a new VS ever since going up to C8:

Performing other Apache configuration …
… configuration failed : PHP execution mode fcgid was selected, but is not supported on this system!!

virtualmin|690x255

it appears the only option i see is “FPM (run as virtual server owner)”

this issue does not seem to affect anything, as everything seems to work just fine.

any suggestions?

Operating system: CentOS8
OS version: CentOS8

That’s the new normal for CentOS 8. There’s a lot about this in previous posts. Unload mod_php and restart the web server for starters.

Why is it trying to use fcgid? It shouldn’t be possible to select it, at all. Did you restore an old Virtualmin config from another server running an earlier CentOS release? Maybe your Server Templates have it set,
or something…

Anyway, fcgid is no longer a supported option in CentOS 8. So, wherever it is configured, undo it. But also tell me how you got there, because it shouldn’t be possible.

Excellent questions, Joe. and unfortunately, i do not know the answers.

you may recall (or perhaps you are suppressing it, understandably so) that last year you patiently worked with me and teaching me to avoiding third party installations, except perhaps for epel.

is there a config file i could send to you that might help determine why this might be happening? or if you want, we could do some sort of screen-share at your convenience, whatever you think.

it MAY be because when i do:

php -v ;

i see:

PHP 7.2.24 (cli) (built: Oct 22 2019 08:28:36) ( NTS )
Copyright (c) 1997-2018 The PHP Group
Zend Engine v3.2.0, Copyright (c) 1998-2018 Zend Technologies
with Zend OPcache v7.2.24, Copyright (c) 1999-2018, by Zend Technologies

i do also see this:

php-fpm -v;

PHP 7.2.24 (fpm-fcgi) (built: Oct 22 2019 08:28:36)
Copyright (c) 1997-2018 The PHP Group
Zend Engine v3.2.0, Copyright (c) 1998-2018 Zend Technologies
with Zend OPcache v7.2.24, Copyright (c) 1999-2018, by Zend Technologies

now i am wondering if i accidentally installed both ordinary php and fpm-php? or are they the same? :thinking:

dnf list installed | grep php;
php.x86_64 7.2.24-1.module_el8.2.0+313+b04d0a66 @AppStream
php-cli.x86_64 7.2.24-1.module_el8.2.0+313+b04d0a66 @AppStream
php-common.x86_64 7.2.24-1.module_el8.2.0+313+b04d0a66 @AppStream
php-devel.x86_64 7.2.24-1.module_el8.2.0+313+b04d0a66 @AppStream
php-fpm.x86_64 7.2.24-1.module_el8.2.0+313+b04d0a66 @AppStream
php-gd.x86_64 7.2.24-1.module_el8.2.0+313+b04d0a66 @AppStream
php-json.x86_64 7.2.24-1.module_el8.2.0+313+b04d0a66 @AppStream
php-ldap.x86_64 7.2.24-1.module_el8.2.0+313+b04d0a66 @AppStream
php-mbstring.x86_64 7.2.24-1.module_el8.2.0+313+b04d0a66 @AppStream
php-mysqlnd.x86_64 7.2.24-1.module_el8.2.0+313+b04d0a66 @AppStream
php-opcache.x86_64 7.2.24-1.module_el8.2.0+313+b04d0a66 @AppStream
php-pdo.x86_64 7.2.24-1.module_el8.2.0+313+b04d0a66 @AppStream
php-pear.noarch 1:1.10.5-9.module_el8.2.0+313+b04d0a66 @AppStream
php-pecl-zip.x86_64 1.15.3-1.module_el8.2.0+313+b04d0a66 @AppStream
php-process.x86_64 7.2.24-1.module_el8.2.0+313+b04d0a66 @AppStream
php-xml.x86_64 7.2.24-1.module_el8.2.0+313+b04d0a66 @AppStream
php-xmlrpc.x86_64 7.2.24-1.module_el8.2.0+313+b04d0a66 @AppStream
php72-php-cli.x86_64 7.2.34-2.el8.remi @remi-safe
php72-php-common.x86_64 7.2.34-2.el8.remi @remi-safe
php72-php-devel.x86_64 7.2.34-2.el8.remi @remi-safe
php72-php-json.x86_64 7.2.34-2.el8.remi @remi-safe
php72-php-pecl-imagick.x86_64 3.4.4-10.el8.remi @remi-safe
php72-php-pecl-imagick-devel.x86_64 3.4.4-10.el8.remi @remi-safe
php72-runtime.x86_64 2.0-1.el8.remi @remi-safe
wbm-php-pear.noarch 2:1.6-1 @virtualmin-universal

By installing php-fpm.x86_64 normal PHP becomes PHP-FPM. That’s what you want and it’s how PHP is shipped with CentOS 8. The output above looks normal except for one thing…

CentOS 8 continues to ship with PHP 7.2 as the default even though AppStream can now provide 7.3 and 7.4. It appears the default hasn’t changed and that you have two parallel installations of 7.2 from two different repos.

If any of these three 7.x versions work for you as the defaullt global PHP installation, there’s no reason to be using Remi’s repo. Currently the only reason for Remi is to replace global PHP with version 8 or for multiple installations that are different from global.

With dnf you can switch the global default and upgrade 7.2 as high as AppStream will go. So with the following you’d be replacing 7.2 with 7.4:

dnf module reset php
dnf module enable php:7.4
dnf update php\*

Installed modules will upgrade too.

To check at the command line use php -v for the global installation and /usr/bin/php72 -v for the extra from Remi. The full path to the binary symlink is necessary for Remi add-on installations, but not for the global default installation.

The global installation uses /etc/php.ini and the extra 7.2 installation from Remi uses /etc/opt/remi/php72/php.ini.

Get rid of extra Remi installations at your leisure but always keep the global installation.

2 Likes

thank you so much Ramin. i am traveling now & cant afford anymore screwups on my part.

are you thinking i should do this? (all the ones with “@remi-safe”)

dnf remove php72-php-cli ;
dnf remove php72-php-common ;
dnf remove php72-php-devel ;
.....
dnf remove php72-runtime;

of course i suspect just doing dnf -y remove php72 ; would do the same, but i need to be extra careful after so many screwups lately.

You could start with dnf remove php72, observe what happens, then use dnf info php72 to see if there are leftovers. PHP’s cli, common and devel will probably be removed along with core packages.

Usually with a Remi PHP installation some dependencies and most PHP extensions install separately from main packages and need to be removed the same way. It’s easier to stack them in a single command.

dnf remove php72-php-fpm php72-php-mysqlnd php72-php-xmlrpc php72-php-pear php72-php-pdo php72-php-opcache

1 Like

Ramin - once again, i sincerely thank you for your assistance.

it was “interesting” to discover how stuff previously installed with pecl and lines in the php.ini file such as:

extension=raphf
extension=imagick
extension=propro

had to be commented out and replaced with:

dnf -y install php74-php-pecl-propro-devel php74-php-pecl-propro
php74-php-pecl-imagick-devel php74-php-pecl-imagick
php74-php-pecl-raphf ;

in order to eliminate errors and warnings when i did:

systemctl  restart  php-fpm ; php -v   ;  php-fpm  -v;

PHP 7.4.6 (cli) (built: May 12 2020 08:09:15) ( NTS )
Copyright (c) The PHP Group
Zend Engine v3.4.0, Copyright (c) Zend Technologies
with Zend OPcache v7.4.6, Copyright (c), by Zend Technologies

now my dnf list installed | grep php; looks like this:

php.x86_64 7.4.6-4.module_el8.3.0+434+2ab5050a @appstream
php-cli.x86_64 7.4.6-4.module_el8.3.0+434+2ab5050a @appstream
php-common.x86_64 7.4.6-4.module_el8.3.0+434+2ab5050a @appstream
php-devel.x86_64 7.4.6-4.module_el8.3.0+434+2ab5050a @appstream
php-fpm.x86_64 7.4.6-4.module_el8.3.0+434+2ab5050a @appstream
php-gd.x86_64 7.4.6-4.module_el8.3.0+434+2ab5050a @appstream
php-json.x86_64 7.4.6-4.module_el8.3.0+434+2ab5050a @appstream
php-ldap.x86_64 7.4.6-4.module_el8.3.0+434+2ab5050a @appstream
php-mbstring.x86_64 7.4.6-4.module_el8.3.0+434+2ab5050a @appstream
php-mysqlnd.x86_64 7.4.6-4.module_el8.3.0+434+2ab5050a @appstream
php-opcache.x86_64 7.4.6-4.module_el8.3.0+434+2ab5050a @appstream
php-pdo.x86_64 7.4.6-4.module_el8.3.0+434+2ab5050a @appstream
php-pear.noarch 1:1.10.12-1.module_el8.3.0+396+9a0d79d6 @appstream
php-process.x86_64 7.4.6-4.module_el8.3.0+434+2ab5050a @appstream
php-xml.x86_64 7.4.6-4.module_el8.3.0+434+2ab5050a @appstream
php-xmlrpc.x86_64 7.4.6-4.module_el8.3.0+434+2ab5050a @appstream
php74-libzip.x86_64 1.7.3-2.el8.remi @remi-safe
php74-php-cli.x86_64 7.4.14-1.el8.remi @remi-safe
php74-php-common.x86_64 7.4.14-1.el8.remi @remi-safe
php74-php-devel.x86_64 7.4.14-1.el8.remi @remi-safe
php74-php-json.x86_64 7.4.14-1.el8.remi @remi-safe
php74-php-pecl-imagick.x86_64 3.4.4-10.el8.remi @remi-safe
php74-php-pecl-imagick-devel.x86_64 3.4.4-10.el8.remi @remi-safe
php74-php-pecl-propro.x86_64 2.1.0-5.el8.remi @remi-safe
php74-php-pecl-propro-devel.x86_64 2.1.0-5.el8.remi @remi-safe
php74-php-pecl-raphf.x86_64 2.0.1-1.el8.remi @remi-safe
php74-php-pecl-raphf-devel.x86_64 2.0.1-1.el8.remi @remi-safe
php74-php-pecl-zip.x86_64 1.19.2-1.el8.remi @remi-safe
php74-runtime.x86_64 1.0-3.el8.remi @remi-safe
wbm-php-pear.noarch 2:1.6-1 @virtualmin-universal

please feel free to share any more wisdom and insight with me.

Well, instead of two 7.2 installations it looks like you now have a pair of 7.4 installations from different repos. And I’m wondering if you’ve possibly got three total if 7.2 from Remi wasn’t removed when 7.4 from Remi was added. Do you see directories for both php72 and php74 when you type ls /etc/opt/remi?

Output from these commands will say for sure if there are two Remi installations:

php72 -v
systemctl status php72-php-fpm
php74 -v
systemctl status php74-php-fpm

If the shorter php?? -v commands aren’t working try full paths:

/usr/bin/php72 -v
/usr/bin/php74 -v

For the global installation it works this way regardless of the version installed:

php -v
systemctl status php-fpm

I think installing 7.4 from AppStream as the global default was the right move. But the 7.4 packages from Remi need to go so that packages come only from CentOS. I’m not clear about what happened but here’s what I think you should do to get on track:

  1. Remove all traces of Remi PHP installations including modules that were added.
  2. Disable all Remi repos when you’re satisfied everything installed from Remi was removed.
  3. Focus on the global PHP installation using only CentOS repos, mainly AppStream.
  4. Run dnf update php\* again to make sure dependencies are resolved by CentOS repos.

To disable Remi repos open every /etc/yum.repos.d/remi* file with an editor and replace enabled=1 with enabled=0. Then run dnf clean all.

Once global PHP is tip-top and working for you, and you decide at some point you need an older 7.x version or want to try PHP 8, you can always re-enable Remi by toggling those 0s to 1s.

1 Like

Ramin, Here is what i am seeing (no php72 available)

which php;

/usr/bin/php

which php-fpm ;

/usr/sbin/php-fpm

/usr/sbin/php-fpm -v ;

PHP 7.4.6 (fpm-fcgi) (built: May 12 2020 08:09:15)
Copyright (c) The PHP Group
Zend Engine v3.4.0, Copyright (c) Zend Technologies
with Zend OPcache v7.4.6, Copyright (c), by Zend Technologies

/usr/bin/php -v ;

PHP 7.4.6 (cli) (built: May 12 2020 08:09:15) ( NTS )
Copyright (c) The PHP Group
Zend Engine v3.4.0, Copyright (c) Zend Technologies
with Zend OPcache v7.4.6, Copyright (c), by Zend Technologies

ls -l /usr/sbin/php* ;

-rwxr-xr-x 1 root root 6379320 Jul 23 15:27 /usr/sbin/php-fpm

ls -l /usr/bin/php*

-rwxr-xr-x 1 root root 6376432 Jul 23 15:27 /usr/bin/php
lrwxrwxrwx 1 root root 32 Jan 5 08:20 /usr/bin/php74 → /opt/remi/php74/root/usr/bin/php
lrwxrwxrwx 1 root root 36 Jan 5 08:20 /usr/bin/php74-cgi → /opt/remi/php74/root/usr/bin/php-cgi
lrwxrwxrwx 1 root root 38 Jan 5 08:20 /usr/bin/php74-phar → /opt/remi/php74/root/usr/bin/phar.phar
-rwxr-xr-x 1 root root 6375920 Jul 23 15:27 /usr/bin/php-cgi
-rwxr-xr-x 1 root root 4031 Jul 23 15:27 /usr/bin/php-config
-rwxr-xr-x 1 root root 4741 Jul 23 15:27 /usr/bin/phpize

i just might go ahead and do: (results of dnf list installed | grep remi;')

dnf remove
 remi-release
 php74-runtime
 php74-libzip
 php74-php-cli
 php74-php-common
 php74-php-devel
 php74-php-json
 php74-php-pecl-imagick
 php74-php-pecl-imagick-devel
 php74-php-pecl-propro
 php74-php-pecl-propro-devel
 php74-php-pecl-raphf
 php74-php-pecl-raphf-devel
 php74-php-pecl-zip

suggestions welcome!

The above packages look like they’re from Remi so might as well remove them.

With third-party repos like Remi and SCL installed it’s important to differentiate how they name their PHP packages. If you accidentally remove something from CentOS AppStream you can always add it back but make sure Remi is uninstalled first.

1 Like

Ramin - thank you so much for helping me, i truly appreciate it.

this is what i see now:

#
# dnf list installed | grep php ;
php.x86_64 7.4.6-4.module_el8.3.0+434+2ab5050a @appstream
php-cli.x86_64 7.4.6-4.module_el8.3.0+434+2ab5050a @appstream
php-common.x86_64 7.4.6-4.module_el8.3.0+434+2ab5050a @appstream
php-devel.x86_64 7.4.6-4.module_el8.3.0+434+2ab5050a @appstream
php-fpm.x86_64 7.4.6-4.module_el8.3.0+434+2ab5050a @appstream
php-gd.x86_64 7.4.6-4.module_el8.3.0+434+2ab5050a @appstream
php-json.x86_64 7.4.6-4.module_el8.3.0+434+2ab5050a @appstream
php-ldap.x86_64 7.4.6-4.module_el8.3.0+434+2ab5050a @appstream
php-mbstring.x86_64 7.4.6-4.module_el8.3.0+434+2ab5050a @appstream
php-mysqlnd.x86_64 7.4.6-4.module_el8.3.0+434+2ab5050a @appstream
php-opcache.x86_64 7.4.6-4.module_el8.3.0+434+2ab5050a @appstream
php-pdo.x86_64 7.4.6-4.module_el8.3.0+434+2ab5050a @appstream
php-pear.noarch 1:1.10.12-1.module_el8.3.0+396+9a0d79d6 @appstream
php-process.x86_64 7.4.6-4.module_el8.3.0+434+2ab5050a @appstream
php-xml.x86_64 7.4.6-4.module_el8.3.0+434+2ab5050a @appstream
php-xmlrpc.x86_64 7.4.6-4.module_el8.3.0+434+2ab5050a @appstream
wbm-php-pear.noarch 2:1.6-1 @virtualmin-universal
#
# dnf list installed | grep remi
remi-release.noarch 8.3-1.el8.remi @remi-safe
#
#
# ls -l /usr/sbin/php-fpm /usr/bin/php ;
-rwxr-xr-x 1 root root 6376432 Jul 23 15:27 /usr/bin/php
-rwxr-xr-x 1 root root 6379320 Jul 23 15:27 /usr/sbin/php-fpm
#
# /usr/sbin/php-fpm -v ;
PHP 7.4.6 (fpm-fcgi) (built: May 12 2020 08:09:15)
Copyright (c) The PHP Group
Zend Engine v3.4.0, Copyright (c) Zend Technologies
with Zend OPcache v7.4.6, Copyright (c), by Zend Technologies
#
# /usr/bin/php -v ;
PHP 7.4.6 (cli) (built: May 12 2020 08:09:15) ( NTS )
Copyright (c) The PHP Group
Zend Engine v3.4.0, Copyright (c) Zend Technologies
with Zend OPcache v7.4.6, Copyright (c), by Zend Technologies

is it “normal” to still see the two different php’s? it looks very encouraging to see the two different php’s have the identical build date/time.

Depending on the system which creates the php builts, it might very well be possible to have different php versions on the same time being finished.
And since you did install them and didn’t remove them, it is pretty much normal that there are multiple versions. If you wanted to remove one of them, then it looks like you just forgot one of them.

This looks just right and I see no discrepancies. By resetting the PHP module to 7.4 earlier with dnf, package management now assumes 7.4 for anything PHP.

Now, if you later decided to add different PHP versions from Remi (any but 7.4), study the configuration wizard at his site. Particularly how yum/dnf usage differs between “single” and “multiple” installations. Your only concern at this point would be how multiples are installed. Your single install is the one you just did with AppStream. I recommend sitting on this one install for simplicity and less maintenance, and especially if 7.4 is all you’ll need.

1 Like

This topic was automatically closed 4 days after the last reply. New replies are no longer allowed.