Beiträge von weltmeister

    Und ich schätze mal, dass wenn jemand merkt dass unter PHP 7.4 ein Fehler auftaucht, er einfach wieder auf 7.3 zurückstellt und das nicht weiter hinterfragt.


    Ganz im Gegenteil: jede 2. Mail lautete "Ihr Server ist Down / Abgstürzt / nicht erreichbar". D.h. die Kunden haben auf PHP 7.4 umgestellt, vermuten dort aber den Fehler nicht. (An dieser Stelle hätte nie jemand nach der Ursache gesucht - das waren immer die gleichen Aussagen). Niemand hat zurückgestellt. Alle Kunden glaubten bisher, der Server wäre "abgestürzt" oder hätte ein Problem. (Dabei war dieser selbst weiterhin erreichbar, nur die entsprechende Kundenseite hat den Fehler ausgegeben.) D.h. die Ursache wurde in 99% aller Support-Anfragen bei uns, also beim Provider gesucht.


    "Der Server ist Down!"
    "Dringend!"
    "Was haben Sie gemacht?"
    "Haben Sie an den Seiten manipuliert?"
    "Warum ist Ihr Server nicht errichbar?"
    "Ich verzichte diesesmal darauf, Sie für die Nicht-Erreichbarkeit in Regress zu nehmen."
    " Meine Seite ist schon den halben Tag nicht erreichbar, es kommen keine Bestellungen rein!"
    "Sofortige Kündigung!"
    "Bei anderen Providern gibt es auch PHP 7.4, dort läuft komischerweise alles!"
    "Sie machen sich Schadensersatzpflichtig!"
    "Ich verlange die sofortige herausgabe meiner Auth-Codes!"


    Das sind nur einige Textauszüge aus den vielen Mails der letzten Tage. Das hat Nerven gekostet...

    Über 9000 Webseiten, verteilt auf 54 Server, allerdings "nur" ca. 3500 Kunden. Bei uns läuft das Hosting als Vollzeiterwerb seit 2007 und wir leben ausschließlich allein davon, d.h. auf funktionierende Systeme sind wir angewiesen.


    Seit dem der Cache gestern abgestellt worden ist, kam keine einzige Anfrage mehr rein. Mal nebenbei bemerkt, das Problem hat uns bisher leider 2 langjährige (zum Glück nur kleinere) Kunden und einen enormen Support-Aufwand gekostet.

    Wir haben nun, um das enorme Support-Aufkommen zu stoppen, überall opcache.enable=0 hinterlegt. Das sollte aber hoffentlich nur eine kurzzeitige Lösung sein, bis es ein Update gibt.

    Was wir nach einigen Tagen festegestellt haben: der Befehl


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


    schafft offensichtlich nur kurzzeitg abhilfe. Die Fehler sind wieder da, selbst wenn man die PHP-Version nicht umstellt. Die Kundenanfragen reißen nicht mehr ab, jetzt sind es fast 200 Anfragen.

    Aktueller Fall aus der Praxis: Kunde hat auf PHP 7.4 umgestellt, die Seite war anschließend nicht erreichbar. Erst durch das löschen des alten Cache war alles wieder funktionstüchtig. D.h. wenn LiveConfig diesen Cache automatisch bei einer PHP-Versionsumstellung löschen könnte, wäre alles gut.


    Wir hoffen auf ein zeitnahes Update.

    Wir hatten gestern auch ca. 40 Mails nur wegen diesem Problem.... und die Lösung ist so einfach!


    Ein Test auf 5 weiteren Servern war erfolgreich. Jeweils war dieser Befehl die Lösung und alles ist wieder erreichbar.

    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?

    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.

    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

    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.

    taenzerme: vielen Dank für die Tipps und den Hinweis mit dem Bug. Das habe ich fast schon vermutet. Schade nur, dass sich hierum bisher noch niemand gekümmert hat, wurde dies doch schon im Juli gemeldet, wenn ich das richtig gesehen habe.


    Die gen. Einstellungen habe ich durchprobiert - leider ohne Erfolg.

    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.

    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:

    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.

    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.


    Last but not least gibt es nun auch fertige PHP-Pakete mit dem IonCube-Loader (aktuellste Version) für PHP 5.6-7.4.


    Eine vielleicht "blöde" Frage: wo findet man diese PHP-Paket und bedeutet dies, das man IonCube nicht mehr manuell (in die php.ini) einbinden muss?