OPCache-Problem

    Vorab: mir ist bewusst, dass dieses Problem zu 99% nicht durch LiveConfig verursacht wird.


    Folgende Grundlage:


    Debian 10
    PHP 7.4
    PHP FPM
    OpCache = an


    Einige Seiten geben nur einen error 503 aus. Sobald man den OpCache deaktiviert, funktioniert alles tadellos.


    Aktiviert man OPCache läuft das error.log mit Meldungen wie diesen über:


    Zitat

    [Wed Aug 19 13:11:05.279713 2020] [proxy_fcgi:error] [pid 22890:tid 139888718919424] (104)Connection reset by peer: [client 49.205.242.146:52191] AH01075: Error dispatching request to :
    [Wed Aug 19 13:11:05.356367 2020] [proxy_fcgi:error] [pid 22890:tid 139888718919424] [client 49.209.2242.146:52191] AH01067: Failed to read FastCGI header


    Nachdem ich nun einen ganzen Tag lang keine Lösung gefunden habe, wollte ich anfragen, ob noch jemand einen Tipp oder gar das gleiche Problem hat?


    Ergänzung: das Problem tritt nur bei PHP 7.4 mit aktiviertem Opcache auf, mit PHP 7.3 und aktiviertem Opcache läuft alles rund.

    Mein Verhältnis zum OpCache ist etwas zwiegespalten (die Tatsache, dass bei FPM der Shared Memory zwischen allen Pools geteilt wird, ist einfach unterirdisch und weltfremd).


    Wenn's mit PHP 7.3 funktioniert und mit 7.4 nicht mehr (ich nehme an, bei der selben Website?), dann deutet das wohl auf ein Problem in PHP selbst hin. LiveConfig hat damit tatsächlich nichts am Hut. ;)


    Was Sie machen können:

    • opcache.error_log setzen (z.B. auf /tmp/opcache.log - die Datei sollte kurzzeitig mode=0777 haben, damit die von allen PHP-Instanzen beschrieben werden darf)
      Am besten direkt in /opt/php-7.4/etc/conf.d/opcache.ini eintragen
    • opcache.log_verbosity_level setzen (am besten auf "2")
    • in den php.ini-Einstellungen des betroffenen Vertrags log_errors auf "on" setzen (damit sollten dann Fehler in ~/logs/priv/php_errors.log protokolliert werden


    ... und dann mal schauen ob irgendwelche weiteren Informationen in den Logs auftauchen.


    Die Apache-Meldung "Connection reset by peer" bedeutet i.d.R. dass der PHP-Prozess während der Verarbeitung der Anfrage abgeraucht ist. Das sollte prinzipiell auch nicht ohne Log-Einträge passieren. Manchmal taucht auch was in den System-Logs auf (/var/log/messages, /var/log/syslog; insbes. wenn ein SEGFAULT aufgetreten ist).

    Danke für die Denkanstöße. Das gleiche Problem tritt übrigens auch auf in folgender Zusammenstellung auf:


    Debian 9
    PHP 7.4
    FastCGI
    OpCache = an


    Es betrifft leider nicht nur eine Webseite, sondern die jenigen, die auf PHP 7.4 umstellen, egal ob Debian 9 oder 10 und FPM oder FastCGI. Ich vermute einen "Konflikt" zwischen OpCache und PHP 7.4.

    Heute hat ein externer Profi gegen Bezahlung einmal über die Sache geschaut. Leider hat er es auch nicht hinbekommen.



    Sobald man auf PHP 7.3 zurückstellt, keinerlei Probleme mit sämtlichen Kundenseiten. Hat jemand ein ähnliches Problem, bzw. wo genau könnte man suchen? Das Problem hat uns nun schon mehrere Tage beschäftigt. :confused:

    Zitat von kk

    Mit welchen Web-Anwendungen lässt sich das Problem reproduzieren?
    Genügt z.B. eine WordPress-Standardinstallation?
    Wenn ja, dann können wir das gerne mal auf anderen Servern testen.


    Korrekt, das Problem tritt z.B. auch bei einer WP-Installation ohne Plugins oder weiteren Anpassungen auf.
    Ansonsten auch bei anderer Software, z.B. Shops usw., die jedoch unter 7.3 tadellos mit OPCache funktionieren.


    Da das ganze nun schon mehrere Tage und mehrere Hundert Euro für den externen Administrator gekostet hat, wäre ich sehr an einer Lösung oder einem Lösungsansatz interessiert. Ich würde auch helfen, wo ich kann, d.h. wenn weitere eingehende Info's o.ä. benötigt werden, bitte gern per Mail melden, wir sind täglich erreichbar.


    Ich weiß, das dieses Problem mit LC sicher nur wenig zu tun hat, daher bedanke ich mich im Voraus für die Unterstützung.

    Hallo weltmeister,


    ich hatte bei uns vor einigen Wochen quasi das gleiche Problem. Aufgefallen ist es mit PHP 7.4 und dem PayPal-Plus-Plugin für WooCommerce. Das blöde an der Nummer: Ich weiß nicht mehr, wie wir es genau gelöst haben. Der OPCache ist aber beim betroffenen Shop wieder aktiviert und PHP 7.4.7 im Einsatz.


    Ich erinnere mich grob, dass u.a. diese OPCache-Einstellungen notwendig waren:


    opcache.load_comments = yes
    opcache.save_comments = yes
    zlib.output_compression = no


    Bei zlib bin ich mir aber nicht sicher, ob das relevant war.


    Viele Grüße
    Sebastian

    Wir haben das inzwischen mal auf folgenden Plattformen getestet:
    - Ubuntu 20.04 LTS mit dem "mitgelieferten" PHP 7.4.3
    - Ubuntu 20.04 LTS mit dem von LiveConfig bereitgestellten PHP 7.4.9
    - Debian 10 mit LiveConfig PHP 7.4.9


    in allen Varianten via FPM, OpCache aktiviert (Standardeinstellungen). WordPress installiert und sowohl Frontend als auch Backend aufgerufen - ohne einen einzigen Fehler.


    Haben Sie noch irgendwelche anderen PHP-Erweiterungen aktiviert? (insbes. sowas wie ionCube-Loader, Zend Optimizer o.ä.)
    Lässt sich das auf anderen Servern (z.B. einer frisch installierten VM) reproduzieren?

    Es ist jeweils noch IonCube aktiv (apt install php-7.4-opt-ioncube), weil einige Kunden diese Erweiterung leider benötigen.


    Auch auf komplett neu aufgesetzten Servern besteht das Problem leider. (Wurde auf 2 neuen Servern getestet) Ich denke mal, das diese Fehler mit dem Bug zusammenhängen müssen.


    Ansonsten laden Sie in die WP-Installation mal ein paar Themes oder Plugins, der Fehler muss dann jedenfalls auftreten.

    Zitat von weltmeister

    Auch auf komplett neu aufgesetzten Servern besteht das Problem leider. (Wurde auf 2 neuen Servern getestet) Ich denke mal, das diese Fehler mit dem Bug zusammenhängen müssen.


    War auf diesen frisch aufgesetzten Servern auch ionCube aktiviert?

    [Nachtrag]     ich sehe eben, auf unseren Testservern (Ubuntu 20, Debian 10) war ioncube auch jeweils aktiviert. Scheint nicht zwingend damit zusammenzuhängen.


    Zitat

    Ansonsten laden Sie in die WP-Installation mal ein paar Themes oder Plugins, der Fehler muss dann jedenfalls auftreten.


    Wäre prima wenn Sie eine exakte Anleitung (also konkrete Themes/Plugins) zum Reproduzieren nennen könnten. Eine frische WordPress-Installation (via Appinstaller) läuft problemlos.

    Hier wäre die Plugin-Liste einer betroffenen Installation:


    wp-youtube-lyte
    wp-vgwort
    wp-optimize
    wp-gdpr-compliance
    wp-external-links
    wordpress-seo
    webp-converter-for-media
    updraftplus
    table-of-contents-plus
    statify
    shortcodes-ultimate
    search-meter
    post-snippets
    plugin-report
    header-footer-code-manager
    gp-premium
    enable-jquery-migrate-helper
    cookie-bar
    block-options
    autoptimize
    aawp


    Theme: generatepress

    Zitat von weltmeister

    Korrekt, das Problem tritt z.B. auch bei einer WP-Installation ohne Plugins oder weiteren Anpassungen auf.
    Ansonsten auch bei anderer Software, z.B. Shops usw., die jedoch unter 7.3 tadellos mit OPCache funktionieren.


    Äh...?
    Bei einer WP-Standard-Installation (wie eben beschrieben) habe ich keine Fehler feststellen können. Ich habe testweise mal das Theme "generatepress" und die ersten 10 der o.g. Plugins installiert - auch ohne Probleme.


    Es fällt mir daher etwas schwer zu glauben, dass das tatsächlich auf verschiedenen Servern (separate Hardware) unter Standardbedingungen auftritt. Eine WordPress-Website mit >20 Plugins ist auch schon fast kriminell, trotzdem sollte das keine Segfaults verursachen.


    Fazit: ich kann leider keinen Fehler reproduzieren, daher kann ich auch nicht weiterhelfen.
    Am besten auch mal auf anderer Hardware (bei VMs also auf einem separaten Host) testen.

    Wir haben aktuell 52 Server, (verschienene Hardware, teilweise Debian 9, teilweise Debian 10) wo dieses Problem auftritt, allerdings ausschließlich unter PHP 7.4


    Kann es evtl. auch den Einstellung in der Datei /etc/apache2/mods-available/fcgid.conf liegen? Wie sind da die empfohlenen Einstellungen für einen fehlerfreien Betrieb, zwecks abgleich?
    Ich weiß ansonsten leider nicht mehr, wo man noch suchen sollte. Ein erfahrener externer Admin ist leider auch gescheitert an dieser Sache.

    Das Problem hatte ich auch schon mit einigen Seiten gehabt. Eventuell ist das hier wichtig: Der Fehler passiert meistens dann, wenn die Seite z.B. unter PHP 7.3 (oder einer anderen unter 7.4) seit längerem läuft, und dann die PHP-Version auf 7.4 geändert wird.


    Bei WP-Seiten die von Anfang an mit 7.4 betrieben werden, ist mir bisher kein Fall bekannt.

    Hmm, sehr interessanter Hinweis - das wäre tatsächlich eine plausible Erklärung.
    Der OpCache speichert seine Daten in ~/tmp/<32_Zeichen>/... - wenn da der von PHP 7.3 "compilierte" Opcode herumliegt und dann plötzlich durch PHP 7.4 wiederverwendet wird könnte es krachen.
    weltmeister: Sie könnten testweise mal auf PHP 7.4 umschalten und direkt danach das tmp-Verzeichnis komplett leeren:

    Code
    rm -rf /var/www/<Vertrag>/tmp/*


    (bitte vorher natürlich prüfen dass da keine anderen wichtigen Dateien wie z.B. Session-Files o.ä. herumliegen)

    kk hat zu 99% die Lösung gefunden: erst der Befehl


    Zitat

    rm -rf /var/www/<Vertrag>/tmp/*


    schafft Abhilfe nach einer beliebigen PHP-Umstellung. D.h. der Cache muss gelöscht werden, damit es zu keinen Fehlermeldungen kommt.


    Ich habe dies so jetzt auf mehreren Servern getestet und betrachte dies als Lösung des Problems.


    @rex: kannst du dies auch probieren und bestätigen?

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!

Benutzerkonto erstellen Anmelden