I know ispconfig is targeted to debian / ubuntu systems. But my install is based on centos for years with a lot of services on it. (yes, have panic to migrate... ) I have built a aditional server with ROCKY-8, and put some adittional php versions on it ( 8.0 8.1 8.2) Every version have their php-fpm init script and I've put those in the respective field on ispconfig config interface, but ispconfig does not restart the service after any change. SO every time we modify a site we must restart the service manually (systemctl restart php82-php-fpm.service ). This is a example of my php-fpm config Path to the PHP-FPM init script php82-php-fpm.service Path to the php.ini directory /etc/opt/remi/php82/ Path to the PHP-FPM pool directory /etc/opt/remi/php82/php-fpm.d PHP-FPM socket directory /var/opt/remi/php82/run/php-fpm/ I've briefly check the /usr/local/ispconfig/server/mods-enabled/web_module.inc.php module, and there appears that on centos systems the php-fpm restart its hardcoded to only one version ($initcommand = 'systemctl restart php-fpm.service'; ). Could this be possible? Any advice to solve this, without hard code all restarts in this file? Thanks and regards
I remember the default php was an issue for this distro. Check your logs and try to search this forum / the internet for related info. You can also monitor any php-fpm and restart it using monit.
Did you enable the additional PHP services as well, by issuing "systemctl enable <php-service>" ? edit You may also want to check the listening setting of each php-fpm service. If there should be any PHP services that use the same listening port, then this can cause problems too.
the 4 php-fpm services are enabled and running. If I configure one site with php 8.2 with php-fpm mode, the site is failed unitl I done a manual "systemctl restart php82-php-fpm.service" . The problem is that ispconfig does not made the restart or reload of this services. May be I don't understand how to config this. __________This is the actual status of the 4 php-fpm services on my system. systemctl |grep php-fpm php-fpm.service loaded active running The PHP FastCGI Process Manager php80-php-fpm.service loaded active running The PHP FastCGI Process Manager php81-php-fpm.service loaded active running The PHP FastCGI Process Manager php82-php-fpm.service loaded active running The PHP FastCGI Process Manager
I've just checked one of my AlmaLinux 8 boxes (where switching of the PHP versions works) and found on mine one difference to yours. I have not specified the FPM socket directory, although I have configured ISPConfig to use sockets for PHP-FPM. Without that socket directory ISPConfig will use by default /var/lib/php5-fpm to store the socket files. It shouldn't make a difference but maybe you want to check all your FPM service configurations, if the socket directory is the problem. btw. Did you also update the default PHP version of your distro, or is it still the default version of EL8 and what is the ISPConfig version that you are using?
Hi Michelangelo I have the default PHP version of rocky 8. (PHP 7.4.33) [root@XXXXX ~]# php -v PHP 7.4.33 (cli) (built: Feb 14 2023 09:19:40) ( NTS ) Copyright (c) The PHP Group Zend Engine v3.4.0, Copyright (c) Zend Technologies with Zend OPcache v7.4.33, Copyright (c), by Zend Technologies Socket directory is not the problem, as you see here; I have 3 webs running now on this server in PHP-FPM 8.2 without problems (after manually restart of service) [root@xxxxx ~]# php -v PHP 7.4.33 (cli) (built: Feb 14 2023 09:19:40) ( NTS ) Copyright (c) The PHP Group Zend Engine v3.4.0, Copyright (c) Zend Technologies with Zend OPcache v7.4.33, Copyright (c), by Zend Technologies [root@obelix ~]# ls -l /var/opt/remi/php82/run/php-fpm/ total 4 -rw-r--r-- 1 root root 7 abr 30 12:37 php-fpm.pid srw-rw---- 1 web203 apache 0 abr 30 12:37 web203.sock srw-rw---- 1 web215 apache 0 abr 30 12:37 web215.sock srw-rw---- 1 web216 apache 0 abr 30 12:37 web216.sock srw-rw----+ 1 root root 0 abr 30 12:37 www.sock [root@xxxxx ~]#
PHP 7.4.33 is not the default version of EL8. That would be PHP 7.2.11, but 7.4.33 shouldn't cause any issues with ISPConfig as well, so this version is actually fine and should nonetheless work. Well, you'll probably have to debug this until you have found the root-cause. Based on the information you have provided, I cannot see anything wrong.
You're right. We updated the base version of this box to php7.4 , and mariadb to a more modern one (there are a moodle install on it that need this update).