php8.3-fpm

Wh1sper

Member
Moin,
vorweg: dies ist kein Hilfeschrei, ich komme mit fastcgi klar, hier geht es nur um das Problem, dass ich gerne verstehen würde warum php-fpm bei mir nicht funktioniert.
Mein Setup:
Ein Debian 11 bullseye wurde auf 12 bookworm upgegradet.
keine großen Probleme.
ISPConfig 3.2.11p1
ispconfig_update.sh --force wurde durchgeführt.

Ich möchte gerne einem Kunden eine Auswahlmöglichkeit der php Versionen bieten.
Das klappt auch im Prinzip. Mit fastcgi geht es, alles gut.

Verwendet habe ich bei der php8.3 Version u. a. folgende Einträge
Code:
Pfad zum PHP-FPM Init Script:      php8.3-fpm
Pfad zum php.ini Verzeichnis:      /etc/php/8.3/fpm/
Pfad zum PHP-FPM Pool Verzeichnis: /etc/php/8.3/fpm/pool.d
PHP-FPM socket directory:          /run/php/
Das ist jetzt eine Momentaufnahme, ich habe auch den socket Eintrag weggelassen und anderes.


Was auf dem Server merkwürdig war, ist
# cat /var/log/php8.3-fpm.log
Code:
[22-Jan-2024 13:42:02] NOTICE: Reloading in progress ...
[22-Jan-2024 13:42:02] NOTICE: reloading: execvp("/usr/sbin/php-fpm8.3", {"/usr/sbin/php-fpm8.3", "--nodaemonize", "--fpm-config", "/etc/php/8.3/fpm/php-fpm.conf"})
[22-Jan-2024 13:42:02] NOTICE: using inherited socket fd=8, "/run/php/php8.3-fpm.sock"
[22-Jan-2024 13:42:02] ERROR: Another FPM instance seems to already listen on /var/lib/php5-fpm/web237.sock
[22-Jan-2024 13:42:02] ERROR: FPM initialization failed
Das fand ich suspekt, habe php-fpm gestoppt und die /var/lib/php5-fpm/web237.sock
jetzt: gelöscht.
Wie php5 auf den Server kommt, k.A das war doch jessie oder so.
nach dem löschen:
Ich habe auch mal mit # ps aux | grep php-fpm geschaut
Code:
root        3687  0.0  0.0    212    64 ?        S    Jan19   0:00 s6-supervise svc-php-fpm
root     2059980  0.0  0.0  38852 20732 ?        Ss   Jan21   0:05 php-fpm: master process (/etc/php81/php-fpm.conf)
bed      2059982  0.1  0.0  41924 16456 ?        S    Jan21   5:03 php-fpm: pool www
bed      2059983  0.1  0.0  39868 14412 ?        S    Jan21   5:03 php-fpm: pool www
bed      2386199  1.7  0.0  41920 16456 ?        S    14:03   4:59 php-fpm: pool www
root     2565449  0.0  0.0 269028 41128 ?        Ss   17:04   0:00 php-fpm: master process (/etc/php/7.4/fpm/php-fpm.conf)
www-data 2565450  0.0  0.0 269488 15756 ?        S    17:04   0:00 php-fpm: pool www
www-data 2565451  0.0  0.0 269488 15756 ?        S    17:04   0:00 php-fpm: pool www
php7.4 ist ja der default. Soweit schon ok
Ergebnis ist weiterhin, das php-fpm nicht funktioniert.
cat /var/log/php8.3-fpm.log liefert nach dem löschen keine Einträge.

im webeiten Log kommt letztlich das:
Code:
[Tue Jan 23 17:30:24.353222 2024] [proxy:error] [pid 2597480] (2)No such file or directory: AH02454: FCGI: attempt to connect to Unix domain socket /run/php/web225.sock (*:80) failed
[Tue Jan 23 17:30:24.353241 2024] [proxy_fcgi:error] [pid 2597480] [client 217.251.n.m:45796] AH01079: failed to make connection to backend: httpd-UDS
Also irgendwas mit UDS=UnixDomain Socket
ICh benutzte zum test eine einfache webseite, die keine extra apache oder php direktiven hat.
Wieso taucht da Proxi mit auf?
Ich habe einiges mehr ausprobiert, aber ohne Erfolg.
Nun ist der Unterschied, ob fastcgi mit oder ohne fpm läuft auf meinen Server ziemlich unrelevant, aber es wurmt mich, dass es das Problem gibt..
Hat jemand eine Idee?
Läuft das bei euch?
Ich liefere gerne noch weitere Daten.
 

Till

Administrator
Das fand ich suspekt, habe php-fpm gestoppt und die /var/lib/php5-fpm/web237.sock
jetzt: gelöscht.
Wie php5 auf den Server kommt, k.A das war doch jessie oder so.
Das ist OK und auch nicht PHP 5. Nummern in Socket Pfaden haben grundsätzlich nichts mit PHP Versionen zu tun. Das ist das globale socket Verzeichnis Deines Systems, das ist also ok und kann auch so bleiben. Sowas bitte nicht löschen oder ändern, denn sonst geht php-fpm nicht mehr.

PHP 8.3 auf Debian ISPConfig installieren und einbinden: https://www.howtoforge.com/ispconfig-php-debian/ Trage das bitte mal exakt so ein wie es im Tutorial steht, socket Directory sollte z.B. leer sein.

Die Anbindung von PHP-FPM ist ein proxy.
 

Wh1sper

Member
Danke Till, das war ja meine erste Herangehensweise. gerade nochmal gemacht.
wieder 503
Code:
[Tue Jan 23 20:14:09.367222 2024] [proxy_fcgi:error] [pid 2744408] [client 217.251.n.m:40040] AH01079: failed to make connection to backend: httpd-UDS
auch mal
service php7.4-fpm gestoppt und gestartet.
Code:
23-Jan-2024 20:17:50] NOTICE: Terminating ...
[23-Jan-2024 20:17:50] NOTICE: exiting, bye-bye!
[23-Jan-2024 20:17:56] NOTICE: fpm is running, pid 2747398
[23-Jan-2024 20:17:56] NOTICE: ready to handle connections
[23-Jan-2024 20:17:56] NOTICE: systemd monitor interval set to 10000ms
 

Till

Administrator
Socket Verzeichnis ist jetzt leer bei allen zusatz PHP Versionen? Du musst danach einaml die PHP version wechseln, damit die neue config aktiv wird. generell falls Du eine der php-fpm Versionen auf der shell manuell gestatet hast oder restartd/reloaded hast, dass muss immer über den systemctl Befehl geschehen, denn falls Du z.B. noch alte init script hast für einige PHHP Versionen, dann blockieren de systemd und dann lassen sich PHP Versionen nicht mehr wechseln oder sockets bleiben hängen.
 

Wh1sper

Member
Code:
# systemctl stop php7.4-fpm
# systemctl start php7.4-fpm
# systemctl status php7.4-fpm
● php7.4-fpm.service - The PHP 7.4 FastCGI Process Manager
     Loaded: loaded (/lib/systemd/system/php7.4-fpm.service; enabled; preset: enabled)
     Active: active (running) since Tue 2024-01-23 20:45:42 CET; 9s ago
       Docs: man:php-fpm7.4(8)
    Process: 2772274 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: 2772271 (php-fpm7.4)
     Status: "Ready to handle connections"
      Tasks: 3 (limit: 77005)
     Memory: 13.4M
        CPU: 48ms
     CGroup: /system.slice/php7.4-fpm.service
             ├─2772271 "php-fpm: master process (/etc/php/7.4/fpm/php-fpm.conf)"
             ├─2772272 "php-fpm: pool www"
             └─2772273 "php-fpm: pool www"

Jan 23 20:45:42 isp systemd[1]: Starting php7.4-fpm.service - The PHP 7.4 FastCGI Process Manager...
Jan 23 20:45:42 isp systemd[1]: Started php7.4-fpm.service - The PHP 7.4 FastCGI Process Manager.

und webseite auf default php mit fpm ..geht nicht und php8.3 mit fpm auch nicht.
socket ist leer war ja nur ein versuch.

Naja vielleicht komme ich mal dahinter, das Problem ist wohl gar nicht so selten, den suchmaschinen treffen zu urteilen. Für heute reicht es erstmal
danke schon mal
 

Till

Administrator
Das Problem ist sehr selten, habe auch noch nie einen Server mit so einem Problem gehabt bei meinen Servern oder den meiner Kunden. Aber wenn es um hundertrtausende Installationen geht wie bei ISPConfig, dann findet man grundsätzlich jedes noch so seltene Problem mit einigen Treffern im Netz. Im Grunde kann es nur vorkommen wenn Du Pfade in den Settings falsch einträgst. Wenn Du das Problem lösen willst, musst Du es systematisch angehen, also schauen ob das pool file im richtigen pool verzeichnis liegt, ob der socket Pfad darin stimmt und dieser mit dem Pfad im vhost Übereinstimmt. Und falsches manuelles starten führt wie oben beschrieben dazu dass systemd die prozesse nicht mehr managen kann, Config Änderungen werden dann nicht übernommen und dies führt dazu dass Sockets Pfade am Ende nicht stimmn.

Was auch noch sein kann ist dass wenn Du selbst angepasst templates oder custom apache oder nginx config nutzt, dann kann dies auch zu solchen fehlern führen wenn die config nicht passt. Hatte gerade vor ein paar tagen jemanden der PHP Versionen nicht wechslen konnte weil er eine custom nginx config genutzt hat in der er den socket pfad fest angegeben hatte.
 

Wh1sper

Member
Mit den Treffern in Google meinte ich nicht ispconfig spezifische, war falsch formuliert.
Werde morgen noch mal systematisch versuchen den fehler einzugrenzen. innerhalb ispconfig sollte das schon passen, aber ich gucke dann nochmal.
 

Wh1sper

Member
Fehler gefunden und beseitigt.
Der Fehler war fehlendes php-fpm
:oops: Mann Mann Mann
Vielen Dank für das Nase drauf stuppen.
 

Werbung

Top