Closed xopez closed 5 years ago
Vielen Dank zunächst für deinen ausführlichen Report.
Ich selbst habe das Problem auch schon beobachtet. Nicht bei mir selbst, aber als Report einer der gehosteten Systeme. Konnte in der error.log vom Webserver ebenso den "Connection reset by peer" Fehler festetellen. Es tritt aber scheinbar nur sporadisch auf.
Im ersten Moment habe ich mir deswegen nichts weiter gedacht. Es handelt sich beim Login um einen $_POST, ebenso auch beim Starten/Stoppen des Bot, wo mir das Problem gemeldet wurde.
2019/01/13 08:28:43 [error] 1627#1627: *1515099 recv() failed (104: Connection reset by peer) while reading response header from upstream, client: XXX.XXX.XXX.XXX, server: ts-n.net, request: "POST /host/rs/XX/webinterface/bot.php HTTP/1.1", upstream: "fastcgi://unix:/run/php/php7.3-fpm.sock:", host: "ts-n.net", referrer: "https://ts-n.net/host/rs/XX/webinterface/bot.php"
Wenn nun also der Webserver einen connection reset feststellt, muss es wohl von der Clientseite kommen.. So zumindest der erste Gedanke. Sprich der Client sendet den $_POST, welchen der Webserver erhalten hat (sonst wäre es nicht in der Log), der Client die Antwort aber nicht möchte oder nicht mehr erreichbar ist. Also die Antwort zum $_POST (ist ausgeführt) kommt beim Client nicht an. Dieser sieht entsprechend eine ladende Seite, vermutlich bis zum Timeout.
Wie man sieht, nutze ich auch PHP 7.3, mittels FPM.
In meiner FPM Log habe ich folgenden Eintrag dazu gefunden
[13-Jan-2019 08:28:43] WARNING: [pool www] child 32559 exited on signal 11 (SIGSEGV - core dumped) after 28401.934110 seconds from start [13-Jan-2019 08:28:43] NOTICE: [pool www] child 20576 started
Nach näherer Überlegung scheint es, als ob der Webserver mit dem "connection reset" den FPM meinte. Ich schätze mal, da ist mit PHP 7.3 etwas faul in Verbindung mit dem FPM Server. Sollte so mit dem Ranksystem nichts zu tun zu haben.
Als temporäre Lösung könnte es helfen in regelmäßigen Abständen den FPM neuzustarten. Oder gänzlich auf den FPM verzichten könnte evtl. auch helfen.
Hier bleibt uns wohl nichts anderes übrig, als auch ein Update von PHP zu warten.
Das könnte unser beschriebenes Problem sein.. wäre also bereits reported.
https://bugs.php.net/bug.php?id=77430
Nextcloud hat im Übrigen das gleiche Problem ;-) https://help.nextcloud.com/t/php-fpm-with-so-many-segmentation-fault/37051
Also wird sehr wahrscheinlich kein Thema des Ranksystems sein.
Scheint sich mit PHP 7.3.2 in Luft aufgelöst zu haben. https://docs.plesk.com/release-notes/onyx/change-log/#contents-17811-mu40 Konnte bis jetzt nichts mehr feststellen.
Ich schließ den Issue mal, da es ja seit 7.3.3 wieder sauber läuft.
Hallo,
ich habe auf PHP 7.3 umgestellt und bekomme nun manchmal den Fehler 503. Glaube aktuell kaum, dass es durch das ranksystem ausgelöst wird, aber es passiert komischerweise nur auf der einen Subdomain. Mit PHP 7.2 hatte ich keine Probleme. Vielleicht hat hier jemand einen Plan. OS: Ubuntu 16.04.5 LTS Produkt: Plesk Onyx 17.8.11 Update Nr. 36 Sowohl mit PHP 7.3 als auch 7.3.1 was heute kam. Auch hier wurde das Thema schonmal aufgegriffen: https://community.woltlab.com/thread/273968-502-bad-gateway-nach-umstellung-auf-php-7-3-0/ und hier: https://talk.plesk.com/threads/php-7-3-fpm-dies-without-a-trace.350761/
Jedoch ist es nicht der gleiche Fehler. Wäre dankbar über Hilfe.
Passiert immer beim Login im Webinterface, sprich Daten eingeben und einloggen. Dann kommt der Fehler. Man klickt auf reload und es geht. Sporadisch passiert das auch mal beim restarten des Bots.
error_log
error.log.1
error.log.2