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
Zitatrm -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.
ZitatAlles anzeigenMeiner und auch Ihrer Meinung nach liegt das Problem am PHP-FPM 7.4 mit OpCache.
Folgende Fehler treten nur auf, wenn dieses Konstrukt aktivert ist:
[01-Sep-2020 11:54:54] WARNING: [pool web7] child 6602 exited on signal 11 (SIGSEGV) after 8.008547 seconds from start
[01-Sep-2020 11:54:54] NOTICE: [pool web7] child 6609 started
Hier stürzt der bearbeitende php-fpm Prozess ab, da falsch auf Speicher zugegriffen wird. (https://de.wikipedia.org/wiki/Schutzverletzung)
Darauf lassen auch die Meldungen im /var/www/web7/logs/priv/php_errors.log
[01-Sep-2020 08:44:49 UTC] PHP Fatal error: Allowed memory size of 8589934592 bytes exhausted (tried to allocate 17179806448 bytes) in /var/www/web7/htdocs/wp-content/plugins/autoptimize/autoptimize.php on line 88
Dort stehen 8 GB Limit, aber 17 GB wollte das Script haben. Mit Debugging steht dann folgendes im Log, entsprechend scheint das Problem in gewisser Weise auch mit dem autoptimize in Verbindung zu stehen. (Bei anderen Kunden sind es auch andere Scripte).
[01-Sep-2020 09:26:50 UTC] PHP Fatal error: Uncaught Error: Call to a member function run() on array in /var/www/web7/htdocs/wp-content/plugins/autoptimize/autoptimize.php:97
Stack trace:
#0 /var/www/web7/htdocs/wp-settings.php(377): include_once()
#1 /var/www/web7/htdocs/wp-config.php(72): require_once('/var/www/web7/h...')
#2 /var/www/web7/htdocs/wp-load.php(37): require_once('/var/www/web7/h...')
#3 /var/www/web7/htdocs/wp-blog-header.php(13): require_once('/var/www/web7/h...')
#4 /var/www/web7/htdocs/index.php(17): require('/var/www/web7/h...')
#5 {main}
thrown in /var/www/web7/htdocs/wp-content/plugins/autoptimize/autoptimize.php on line 97
Schlussendlich vermute ich einen Bug der in Verbindung mit bestimmten Scripten und aktiviertem OpCache zu diesem abstürzenden/speicherfressenden PHP-Prozess führt. Ob der Bug in PHP selbst ist oder in den Scripten selber kann ich leider nicht bestimmen.
Hier eine Liste der Scripte in denen Uncaught Errors geschehen
PHP Fatal error: Uncaught Error: Call to a member function switch_to_blog() on null in /var/www/web10/htdocs/wp-includes/cache.php:220
PHP Fatal error: Uncaught Error: Call to a member function switch_to_blog() on null in /var/www/web11/htdocs/wp-includes/cache.php:220
PHP Fatal error: Uncaught Error: Call to a member function switch_to_blog() on null in /var/www/web12/htdocs/wp-includes/cache.php:217
PHP Fatal error: Uncaught Error: Call to a member function run() on string in /var/www/web4/htdocs/wp-content/plugins/autoptimize/autoptimize.php:97
PHP Fatal error: Uncaught Error: Call to a member function run() on string in /var/www/web5/htdocs/wp-content/plugins/autoptimize/autoptimize.php:97
PHP Fatal error: Uncaught Error: Call to a member function run() on string in /var/www/web7/htdocs/wp-content/plugins/autoptimize/autoptimize.php:97
PHP Fatal error: Uncaught Error: Call to a member function run() on array in /var/www/web7/htdocs/wp-content/plugins/autoptimize/autoptimize.php:97
PHP Fatal error: Uncaught Error: Call to a member function run() on string in /var/www/web7/htdocs/wp-content/plugins/autoptimize/autoptimize.php:97
PHP Fatal error: Uncaught Error: Call to a member function run() on bool in /var/www/web7/htdocs/wp-content/plugins/autoptimize/autoptimize.php:97
PHP Fatal error: Uncaught Error: Call to a member function run() on string in /var/www/web7/htdocs/wp-content/plugins/autoptimize/autoptimize.php:97
PHP Fatal error: Uncaught Error: Call to a member function run() on array in /var/www/web7/htdocs/wp-content/plugins/autoptimize/autoptimize.php:97
PHP Fatal error: Uncaught Error: Call to a member function switch_to_blog() on null in /var/www/web9/htdocs/wp-includes/cache.php:217
Wie vorhin angesprochen bleiben Ihnen meines Erachtens aktuell nur die Workarounds:
1. PHP-FPM 7.3 mit OpCache
2. PHP-FPM 7.4 ohne OpCache für die betroffenen Seiten (ggf. mit der kunden-/vertragsspezifischen Option opcache.enabled)
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.
Installiert und gestestet - funktioniert einwandfrei!
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.
Vielen Dank!
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?
Kann ich so auch bestätigen (Firefox, neueste Version).
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.
Die Ursache wurde nach längerer suche nun gefunden:
Die Datei daily.cld in /var/lib/clamav war beschädigt, somit konnte der Dienst, wie vermutet, nicht starten.
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:
Zitat4.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:
ZitatTue 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!
Was ich (und vor allem aber unseren Kunden) noch vermisse: https://www.liveconfig.com/de/…erschieben-statt-abweisen
Wird es diese Möglichkeit mit dem nächsten Update noch geben?
