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?
Vielen Dank, dann freuen wir uns schon auf das kommenden Update.
Updates installiert - vielen Dank dafür!
Nachfrage: ist diese Funktion mit der aktuellen neuen Version schon integriert?
Eine simple Funktion, ganz unkompliziert ein Zertifikat für den eigenen Server anlegen zu können vermisse ich auch. Alles andere ist nur "Bastelei", was wesentlich einfacher funktionieren könnte, per einfachem Klick.
Mit LiveConfig v2.9.2 wird es auch möglich sein, Wildcard-Domains bei den Postfach-spezifischen Blacklists/Whitelists anzugeben - zum Beispiel *.example.org oder sogar *.tld.
Viele Grüße
-Klaus Keppler
Vielen Dank, auch unsere Kunden warten schon lange auf diese Funktion.
Bisher lese ich kein vernünftiges Gegenargument. Es geht hier um die wünsche der Kunden und nicht die des Providers!
Wer diese Funktion nicht braucht, muss diese nicht aktivieren. So einfach ist das ganze!
Nachsatz. Ich gönne Dir selbststrebend diese Funktion (samt dem daraus resultierenden Supportaufkommen). Ich für mich würde aber gerne solche sinnfreikontakte mit unseren Kunden für meine Firma vermeiden, gibt nämlich nur Ärger beim Kunden.
Warum gibt es dann Ärger beim Kunden? Wenn dieser selbst die Mails in einen Ordner (statt in den Posteingang) umleiten lässt, ist er sich ganz klar bewusst was er macht. Braucht der Kunde diese Funktion nicht, muss er den Haken ja nicht setzen. So einfach ist das!
