crash - PHP Fehler /proc flooding [GELÖST]

[Ralph]

Ok, ich hab das "error_log" jetzt überall rausgenommen, allerdings auf die Schnelle nicht manuell

Code: Select all

# tables: php_settings + account_templates - alle aktualaisieren
UPDATE `php_settings` SET `disable_functions` = replace(disable_functions, 'error_log, ', '');
UPDATE `account_templates` SET `php_disable_functions` = replace(php_disable_functions, 'error_log, ', '');

# alle php user conf  aktualaisieren
find /etc/php/8.2/fpm/keyhelp_pool -type f -exec sed -i 's|error_log, ||g' {} \;
find /opt/keyhelp/php/*/etc/php-fpm.d -type f -exec sed -i 's|error_log, ||g' {} \;

# alle PHP services neu gestartet
systemctl status php8.2-fpm.service
systemctl restart keyhelp-php70-fpm.service
systemctl restart keyhelp-php71-fpm.service
systemctl restart keyhelp-php72-fpm.service
systemctl restart keyhelp-php73-fpm.service
systemctl restart keyhelp-php74-fpm.service
systemctl restart keyhelp-php80-fpm.service
systemctl restart keyhelp-php81-fpm.service
systemctl restart keyhelp-php83-fpm.service
systemctl restart keyhelp-php84-fpm.service

ich hoffe das reicht damit aus und es ist richtig so

Allerdings ist damit nicht allein die Ursache für die oben genannten Probleme komplett behoben ...

[24unix]

Code: Select all

UPDATE `php_settings` SET `disable_functions` = replace(disable_functions, 'error_log, ', '');

Hast Du damit nicht ein Komma zu viel?

[Ralph]

Code: Select all

UPDATE `php_settings` SET `disable_functions` = replace(disable_functions, 'error_log, ', '');

Hast Du damit nicht ein Komma zu viel?

das sollte so passen ... ist hier schwer zu erkennen, kopiere es mal plain in einen text editor

Code: Select all

'vorher, ', 'nacher'

das Komma vom "error_log, " mit space wird rausgefischt und mit 'nix' ersetzt, also gelöscht, quasi ...
Sieht alles sauber aus in den Account Templates und in den User settings + User .conf

[24unix]

das sollte so passen ... ist hier schwer zu erkennen, kopiere es mal plain in einen text editor

Stimmt, Asche über mein Haupt, sah wirklich in meinem Kopf anders aus
Aber als ich es dann rauskopiert habe, sortierte es sich wieder

[Ralph]

Stimmt, Asche über mein Haupt, sah wirklich in meinem Kopf anders aus

Kein Problem, vielen Dank fürs drüberschauen!

[24unix]

Stimmt, Asche über mein Haupt, sah wirklich in meinem Kopf anders aus

Kein Problem, vielen Dank fürs drüberschauen!

Mache ich bei solchen Sachen immer.

a) Ich könnte was lernen.
b) Ich könnte helfen.

Beides charmante Optionen

[Alexander]

Bei den kompilierten PHP packages, scheint "max_execution_time" nicht berücksichtigt zu werden bzw. bei überschreiten nicht gekillt.

Bei welchem OS, Architektur und welcher PHP-Version trat das auf?
Ich habe jetzt nur mal schnell alle PHP-Versionen auf Ubuntu 24 auf amd64 getestet und konnte es nicht reproduzieren.

(Mein Test: Alles auf Standard-Einstellungen lassen, und einfach mit "sleep(80);" schauen, ob das Script durchlaufen darf, oder vorher bei Standard 60sek. abbricht)

Ich erinnere mich nicht wo das error_log herkommt, war "error_log" vorher mal in den standard disable_functions?
Im Demo und bei einer neuen Installation scheint es nicht mehr vorhanden zu sein, ich hatte die Account Templates von einem x86 importiert ...

error_log ist seit KeyHelp 24.1 nicht mehr Teil der disable_function des Standard und Unlimited Templates. Also Ja, es stammt in deinem Fall aus deinen alten Vorlagen. Benutzerdefinierte Vorlagen rühre ich mit einem Update nicht an.

[Ralph]

Bei welchem OS, Architektur und welcher PHP-Version trat das auf?

Bezgl. max_execution_time das ist mir nur beim ARM aufgefallen, das Log zeigte einen 500er aber der zugehörige PHP Prozess wurde nicht gestoppt und lief dann endlos mit 100% Last.
Ich vermute diese Reaktion könnte aber auf das error_log in disable_functions zurückzuführen sein ...
Hier handelte es sich um eine alte Wordpress 5.6 auf, habe versucht die zumindest auf 7.4 umzustellen um das Update zu forcieren ... bei PHP 7.3 ist dann der Prozess einfach weitergelaufen und die Seite wurde nicht geladen. Nach umstellen auf PHP 7.1 war das wieder OK.
Diesen Fehler nachzustellen "Call to undefined function" auf ARM am besten eine alte WP verwenden < 6.0 und mal auf PHP 7.3 testen.
Dieser Part betrifft also erstmal nur ARM PHP.

error_log ist seit KeyHelp 24.1 nicht mehr Teil der disable_function des Standard und Unlimited Templates. Also Ja, es stammt in deinem Fall aus deinen alten Vorlagen. Benutzerdefinierte Vorlagen rühre ich mit einem Update nicht an.

Danke, dann nehme ich das bei allen Systemen auch x86 mal raus
Es scheint bei x86 ignoriert zu werden, der Hänger ist mir bisher nur auf 2 arm Systemen aufgefallen ...


Bei allen Systemen fällt hier nur immer ins Auge "Call to undefined function", vieleicht gibt es ja einen Weg diese notice logs irgendwie zu reduzieren, diese waren auch der Verursacher für das 95GB log file bei einem x86.

[Ralph]

Gestern Abend kam es wieder zu einem 40GB error.log innerhalb von 15 Minuten ...
Ein Kunde hat versucht eine Joomla auf PHP 7.4 zu aktualisieren, das verwendete Theme war allerdings nicht kompatibel und es wurden hunderttausende "undefined constant" Meldungen ins error.log des Kunden geschrieben.
Fail2ban geht dabei ebenfalls in die Knie und produziert durch die Größe des Log files eine extrem hohe CPU Load, ein SSH Login hat etwas über 2 Minuten gedauert, danach mußte ich F2B killen um den Fehler zu lokalisieren und zu beheben.

Code: Select all

AH01071: Got error 'PHP message: PHP Warning:  Use of undefined constant Y - assumed 'Y' (this will throw an Error in a future version of PHP)

Mir ist dieses Problem bisher nur bei den komplierten PHP Versionen aufgefallen (kann nicht mit Sicherheit sagen ob es auch die Standard PHP Version betreffen könnte) also ein log flooding durch "Use of undefined constant" warnings ... AH01071 messages.

[Tobi]

Ein Kunde hat versucht eine Joomla auf PHP 7.4 zu aktualisieren,

LOL

[Ralph]

LOL

Haha ist auch keine Lösung
PHP 7.4 wird derzeit noch viel verwendet (Debian11 LTS läuft z.b. noch bis July 2026) Leute fangen nur langsam an auf PHP 8.x umzustellen, das wird dann nur problematisch wenn die log files mit warnings geflutet werden. Ob ein CMS Update von PHP 7.4 auf 8.x nun Sinn macht oder ob überhaupt noch etwas Sinn macht auf diesem Kack-Planeten möchte ich hier nicht diskutieren, aber ich denke mal es ist legitim wenn ein Kunde ein Update durchführen möchte.

[Tobi]

Für mich lag der Witz woanders.

Wie alt muss ein CMS sein welches man JETZT erst auf 7.4 hieven will?
Wie tot muss das Theme sein da es nicht mal 7.4 unterstützt?

Das Anliegen deines Kunden ist mehr als nur legitim. Es ist absolut essenziell und unerlässlich.
Ich drücke ihm die Daumen dass es klappen mag.

Aus meiner Erfahrung heraus würde ich das aktuelle Problem aber als Chance begreifen und das CMS gleich mit der PHP Version wechseln

[Ralph]

Aus meiner Erfahrung heraus würde ich das aktuelle Problem aber als Chance begreifen und das CMS gleich mit der PHP Version wechseln

Schon richtig Tobi, bevor man mit Updates beginnt müssen auch alle Scripts kompatibel sein (normal sterbliche Kunden wissen das nicht) ...
Aber es geht hierbei darum das logging für "Use of undefined constant" warnings in den Griff zu bekommen, damit ein System wg. so einem Unfug nicht überquillt und nicht mehr zugänglich wird. Ich habe innerhalb 15 Minuten eingreifen können weil eine Warn Email gesendet wurde ... ich schätze mal 1 Stunde später wäre das System komplett abgerauscht. Das flooding passiert erschreckend schnell!

[Alexander]

Es gibt eine PHP INI Anweisung fürs Logging, die mehrfaches Loggen des selben Fehlers verhindert. Ggf. gibts du das dem Kunden in seiner Config mal mit.
Es wird sicher nicht funktionieren, wenn der Fehler mit jedem Request ausgelöst wird, und nur, wenn er während einer Abarbeitung eines Requests mehrfach auftritt.

ini_set("ignore_repeated_errors", true);

bzw.

ignore_repeated_errors = 1

[Ralph]

Es gibt eine PHP INI Anweisung fürs Logging, die mehrfaches Loggen des selben Fehlers verhindert. Ggf. gibts du das dem Kunden in seiner Config mal mit.
Es wird sicher nicht funktionieren, wenn der Fehler mit jedem Request ausgelöst wird, und nur, wenn er während einer Abarbeitung eines Requests mehrfach auftritt.

ini_set("ignore_repeated_errors", true);
bzw.
ignore_repeated_errors = 1

Danke Alex!
ich mache das mal so .... eventl. gleich bei allen Kandidaten die in Frage kommen
Hatte leider bisher nicht die Zeit um eine Systemweite Lösung zu finden ... selbiges Problem wird ja auch auftreten wenn z.b. bei einem Theme Entwickler eine Variablendeklaration vergessen/übersehen wird ...
Ich denke da z.b. an etwas wie Log Bedingung prüfen für "AH01071" das globale logging auf ignore_repeated_errors zu setzen oder z.b. via regex check auf "undefined constant" und diese Meldung dann nur einmal loggen (eventl. pro Tag).