Hello All, according to Till's very helpful tutorial, we installed php 7.2 on our Debian 9.5 ISPConfig Server. We use sury.org to install php 7.2 over apt. We then manually make them known to the system via the ISPConfig interface as an additional PHP version. However, if one or multiple pages are configured with PHP-PFM, ISPConfig creates the variable for *.sock in the *.conf files, for each page with a default value. That leads to a "503 Service Unavailable" error. ([proxy:error] [pid 18991] (2)No such file or directory: AH02454: FCGI: attempt to connect to Unix domain socket /var/lib/php7.0-fpm/web11.sock (*) failed) Sometimes, the first and only one Page in ISPConfig is configured with PHP-PFM, it works well. If a second is configured with PHP-PFM we get a 503 error. /etc/apache2/sites-available/anydomain.de.vhost: ISPConfig generates with PHP-PFM 7.2 configured: We have to change all /var/lib/php7.0-fpm/web11.sock -> /run/php/php7.2-fpm.sock (/run/php/web11.sock should work too) PHP: ... <IfModule mod_fastcgi.c> <Directory /var/www/clients/client0/web11/cgi-bin> Require all granted </Directory> <Directory /var/www/anydomain.de/web> <FilesMatch "\.php[345]?$"> SetHandler php-fcgi </FilesMatch> </Directory> <Directory /var/www/clients/client0/web11/web> <FilesMatch "\.php[345]?$"> SetHandler php-fcgi </FilesMatch> </Directory> Action php-fcgi /php-fcgi virtual Alias /php-fcgi /var/www/clients/client0/web11/cgi-bin/php-fcgi-*-80-anydomain.de FastCgiExternalServer /var/www/clients/client0/web11/cgi-bin/php-fcgi-*-80-anydomain.de -idle-timeout 300 -socket /var/lib/php7.0-fpm/web11.sock -pass-header Authorization -pass-header Content-Type </IfModule> <IfModule mod_proxy_fcgi.c> #ProxyPassMatch ^/(.*\.php[345]?(/.*)?)$ unix:///var/lib/php7.0-fpm/web11.sock|fcgi://localhost//var/www/clients/client0/web11/web/$1 <Directory /var/www/clients/client0/web11/web> <FilesMatch "\.php[345]?$"> SetHandler "proxy:unix:/var/lib/php7.0-fpm/web11.sock|fcgi://localhost" </FilesMatch> </Directory> </IfModule>... And in /etc/php/7.2/fpm/pool.d/web11.conf ISPConfig generates: PHP: [web11]listen = /var/lib/php7.0-fpm/web11.socklisten.owner = web11listen.group = www-datalisten.mode = 0660... We have to change /var/lib/php7.0-fpm/web11.sock -> /run/php/php7.2-fpm.sock listen.owner we set to www-data (web11 should work too I think?) If done, then no 503 error will be thrown anymore. I think this is a fundamental bug in the templates used to generate the conf files?! Can we edit these templates ourselves? If so, where are these stored? Thanks and best regards. Helmut
The socket path as created by ispconfig is fine, for web11 the path has to be /var/lib/php7.0-fpm/web11.sock independantly of the used PHP version, the 7.0 in the path does not refer to the PHP version used by that site, its just an ordinary folder name and in this case the system wide PHP socket folder used by all PHP versions. I use several PHP versions from sury here with multiple websites and don't have any issues and there are a few hundred thousand ISPConfig installs that use multiple PHP versions which work without issues as well, so you can rest assured that there is no template bug and that the path is correct. Changing the path manually to /run/php/php7.2-fpm.sock is a huge mistake though as you switched the PHP user from web user to www-data by that which allows access from all sites on your server to other sites and CMS updates will fail on all sites, so revert that. Most likely one of your PHP FPM daemons is not working correctly or it has not been started by systemd which can cause daemon reload failures, try to restart the daemons for all versions or reboot the server.
Thank You Till, for your very quick reply! Thanks for the tips, I'll continue my search for the actual cause. "Bug" was indeed an unfortunate term, "unexpected behavior" would have been better!!! Best regards. Helmut
What actually matters is that the path in: SetHandler "proxy:unix:/var/lib/php7.0-fpm/web11.sock|fcgi://localhost" is the same than the path in listen = /var/lib/php7.0-fpm/web11.sock and the folder part of the path must exist, which is '/var/lib/php7.0-fpm' here. The path defined in the pool config file tells the PHP 7.2 FPM daemon to create a socket with that path and the apache config tells apache to connect to that path. And when this does not work, then probably php-fpm has not created the socket in the named path or it was still there from the other php-fpm version. Sometimes on some servers, php-fpm seems to hang in a way that the old PHP version does not release the socket which makes the new version failt o create it again, that's why a restart of the php-fpm daemons might help.
I think we're getting closer. To rule out that the website in question is responsible, I have configured another one identical to PHP-PFM 7.2. Now ISPConfig has rewritten all configurations, including the paths we replaced. And see there, now the web11 site suddenly works fine with PHP-PFM 7.2. However, the new PHP-PFM 7.2 page now generates a 503 error. This supports your thesis that php-fpm seems to hang. ...
Maybe you can get some more insights by using debug mode: https://www.faqforge.com/linux/debugging-ispconfig-3-server-actions-in-case-of-a-failure/
No errors if I switch the configurations. Absolutely no abnormalities, ISPConfig works works perfectly. I have now changed the configurations to Fast-CGI 7.2. These are similarly fast and work without problems on this server.
