Beiträge von weltmeister

    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?

    Diesem Wunsch schließe ich mich an, eine technische Möglichkeit zu schaffen, Kunden mit "allem drum und dran" problemlos auf andere Server verschieben zu können, ohne das alles manuell angelegt und kopiert werden mus.

    Seit heute gibt es ein bisher unlösbares Problem auf einem von 50 LiveConfig-Servern. Einige Kunden meldeten sich, das deren Mailprogramme folgende Meldungen ausgegeben haben:


    Zitat

    4.7.1 service unavailable - try again later


    Die Ursache dafür wurde gefunden: clamav war als "Virenschutz" in den Maileinstellungen aktivert, was bisher über Jahre keine Probleme verursacht hat.


    Sobald man unter Serververwaltung ---> E-Mail ---> Postfix ---> Viren/Spam den Haken bei ClamAV entfernt, funktioniert alles wieder.


    Auf 49 weiteren Servern besteht das Problem nicht. Auch ein Neustart aller Dienste und des ganzen Servers haben nichts gebracht. Die config-Dateien stimmen mit den anderen Servern 1:1 überein.


    Auszug aus der clamav-milter.log:


    Zitat

    Tue May 19 20:11:33 2020 -> WARNING: No clamd server appears to be available
    Tue May 19 20:11:40 2020 -> ERROR: Failed to initiate streaming/fdpassing
    Tue May 19 20:11:40 2020 -> WARNING: No clamd server appears to be available
    Tue May 19 20:11:42 2020 -> ERROR: Failed to initiate streaming/fdpassing
    Tue May 19 20:11:42 2020 -> WARNING: No clamd server appears to be available


    Hat jemand einen zielführenden Lösungsansatz?


    Vielen Dank im Voraus!