crash - PHP Fehler /proc flooding

[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.