bad gateway nach Umstellung auf php8.1

[katasun]

ISPConfig 3.2.9 | Debian 11 | nginx | php7.4 | php8.1 / websocks - denied - not found

Guten Tag, folgende Frage habe ich nach der Erweiterung auf php 8.1

auf meinem Server lief ISPConfig 3.2.9 mit Debian 11, nginx und php7.4 ohne Fehlermeldungen.

für einige Anwendungen benötige ich php8, deshalb habe ich die PHP Versionen nach Anleitung:

How to install PHP 5.6 and 7.0 - 8.3 with PHP-FPM and FastCGI mode for ISPConfig 3.2 with apt on Ubuntu 20.04 - 22.04

When using ISPConfig, by default, you only have the main PHP version for your distribution. This guide will show you how to install additional PHP ver...

www.howtoforge.com

um php8.1 erweitert. PHP 7.4. ist die default Einstellung, so wie in der Anleitung beschrieben.

Ein Teil meiner bestehenden Webseiten hat die Umstellung ( z.B. Wordpress )von php7.4 auf php8.1 ohne Probleme vertragen. Wenn ich aber neue Webseiten anlege oder versuche die Nginx Konfigurationsdatei für Nextcloud anzupassen bekomme ich Probleme mit den Websocks.

Bei den Neuinstallationen gibt es keine passenden websocks, diese sind also nicht im entsprechenden Verzeichnis vorhanden. connect() to unix:/var/lib/php8.1-fpm/web18.sock failed (2: No such file or directory)

Bei den bestehenden Installationen wird aber auf unix:/var/lib/php7.4-fpm/web9.sock zugegriffen wenn ich das in der neuen Konfiguration ( angepasst )eintrage gibt einen access denied Fehler.

Ich habe im Konfigurationsfile von ISPConfig für Nginx alle Variationen probiert, zum Beispiel

fastcgi_pass unix:/var/lib/php7.4-fpm/web9.sock;
fastcgi_pass unix:/var/lib/php8.1-fpm/web9.sock;

aber auch wenn ich eine bestehende Konfigurationsdatei benutze ( angepasst ), die an andere Stelle funktioniert, klappt es in der neuen Webseite nicht. Weitere Fehlermeldungen hat der Server nicht, es geht also speziell darum php8.1 anzusprechen. Bei meinen neuen Testwebseiten geht weder php7.4 noch php8.1 und im Browser gibt es einen 502 Bad Gateway: nginx/1.18.0 weil ja der Zugriff auf php-fpm fehlschlägt.

1. Frage wird bei der Konfigurationdatei für NGinx weiterhin php7.4 benutzt?
2. Wo und wie kann ich die Websocks testen oder Einstellungen anpassen, damit es wieder funktioniert.

Vielen Dank für jeden Tipp, die Standardfehlermeldungen, error.log oder nginx ermerg sagen mir zu wenig über die Herkunft des Fehlers.

 

[Till]

Bei den Neuinstallationen gibt es keine passenden websocks, diese sind also nicht im entsprechenden Verzeichnis vorhanden. connect() to unix:/var/lib/php8.1-fpm/web18.sock failed (2: No such file or directory)

Das ist richtig und ok so, da alle Sockets immer im globalen Verzeichnis liegen. Bitte nicht sockets manuell auf /var/lib/php8.1-fpm/web9.sock; ändern, da das nicht der richtige Pfad ist. Das richtige Systemweite Verzeichnis auf Debian 11 ist /var/lib/php7.4-fpm/ für alle PHP Versionen, die Zahl im Pfad 7.4 hat nichts mit der in der Website verwendeten PHP version zu tun.

Der wahrscheinlichste Grund für den fehler ist dass in den additional PHP Einstellungen der Pfad zum php-fpm init script falsch eingestellt ist oder php8.1-fpm manuell falsch gestartet wurde und daher nicht von systemd neu gestartet werden kann. Der Pfad zum php-fpm init script muss "php8.1-fpm" sein und Du solltest PHP 8.1 mal stoppen .it:

systemctl stop php8.1-fpm

dann mit ps schauen ob wirklich keine php 8.1 prozesse mehr da sind und dann php8.1-fpm wieder starten:

systemctl start php8.1-fpm

 

[katasun]

Vielen Dank für Deine schnelle Antwort.

tatsächlich war ein Konfigurationsfehler der falsche Pfad zu php8. Aber für den nächsten mit diesem Problem, das erscheint dann als Fehler im Fehlerprotokoll.

Hier auch mal ein paar Befehle, die keine Fehler aufweisen dürfen aber Fehlermeldungen ausgeben, falls die Konfiguration nicht stimmt.

sudo service php7.4-fpmstart
sudo service php7.4-fpm stop
sudo service php7.4-fpm restart
<- restart it
sudo service php7.4-fpm reload
<- reload it

sudo service php8.1-fpmstart
sudo service php8.1-fpm stop
sudo service php8.1-fpm restart
<- restart it
sudo service php8.1-fpm reload
<- reload it

sudo service php7.4-fpm status
● php7.4-fpm.service - The PHP 7.4 FastCGI Process Manager
Loaded: loaded (/lib/systemd/system/php7.4-fpm.service; enabled; vendor preset: enabled)
Active: active (running) since Sat 2022-12-03 20:24:04 CET; 19h ago
Docs: manhp-fpm7.4(8)
Process: 1268 ExecStartPost=/usr/lib/php/php-fpm-socket-helper install /run/php/php-fpm.sock /etc/php/7.4/fpm/pool.d/www.conf 74 (code=exited, status=0/SUCCESS)
Main PID: 953 (php-fpm7.4)
Status: "Processes active: 0, idle: 7, Requests: 9956, slow: 0, Traffic: 0.2req/sec"
Tasks: 9 (limit: 19051)
Memory: 446.9M
CPU: 28min 24.424s
CGroup: /system.slice/php7.4-fpm.service
├─ 953 php-fpm: master process (/etc/php/7.4/fpm/php-fpm.conf)
├─ 1262 php-fpm: pool apps-{fpm_domain}
├─ 1263 php-fpm: pool apps-{fpm_domain}
├─ 1264 php-fpm: pool ispconfig
├─ 1265 php-fpm: pool ispconfig
├─ 1266 php-fpm: pool www
├─ 1267 php-fpm: pool www
├─211494 php-fpm: pool web3
└─211496 php-fpm: pool web3

Mein Problem war folgendes:

in den Einstellungen von /etc/nginx/sites-available gab es zwei Einträge bei zwei Webseiten, die

location @php {
try_files $uri =404;
include /etc/nginx/fastcgi_params;
fastcgi_pass 127.0.0.1:9010;
fastcgi_index index.php;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
fastcgi_intercept_errors on;
}

nicht die socks benutzt haben, sondern über die Ports zugreifen wollten. Das habe ich abgeändert in
fastcgi_pass unix:/var/lib/php7.4-fpm/web1.sock;

Die richtige Konfiguration wurde aber auch nach einem reload von nginx nicht übernommen und ich habe die Änderung per Hand in die sites-enabled eingetragen. Dann wurden die Änderungen auch aktiv. Vielleicht ist das ein spezielles Problem bei mir gewesen. Aber falls jemand auch socks Probleme hat, in beide Konfigurationsdateien auf Konsolenebene reinschauen - enabled und available.

Vielen Dank für die Hilfe
Katasun

 

[Till]

Keines falls die Dateien manuell ändern, denn spätestend wenn Du das nächste mal ISPConfig nutzt wird es dann Probleme geben und der webserver ist ggf. komplett down dann. Also niemals manuell eine vhost Datei anpassen, stattdessen den zugrundeliegenden Fehler beheben. Siehe debug mode.

 

[katasun]

Da hast Du sicher zu 100% recht, aber irgendwann bin ich halt auch genervt und will nur mal "schnell" wissen, was passiert, wenn ich mal was "probiere".