Page 4 of 4

Re: crash - PHP Fehler /proc flooding

Posted: Sat 21. Jun 2025, 08:10
by Ralph
24unix wrote: Fri 20. Jun 2025, 20:57 In KeyHelp werden aber nicht die Pakete von Sury genutzt.
Ich wurde hier ansetzen:

Code: Select all

error_reporting(E_ALL & ~E_DEPRECATED & ~E_NOTICE & ~E_WARNING);
Und das am besten im CMS (welches auch immer das ist).
Es lässt sich nicht genau voraussehen wo dieses Problem auftreten kann, wie gesagt auch ein neuen CMS welches unbeabsichtigt oder beabsichtigt PHP inkompatibelen Code enthält, kann den Stein ins rollen bringen.
Systemweit könnten PHP eigene Konfigurationsoptionen helfen, wenn diese denn vorhanden wären ... momentan eventl. eigene Filter Optionen die für PHP error logging greifen ... es ist halt eine blöde Situation weil niemand sich zuständig fühlen möchte :mrgreen:

Re: crash - PHP Fehler /proc flooding

Posted: Sat 21. Jun 2025, 09:37
by Ralph
Eine mögliche "einfache" Lösung wäre z.b. den betreffenden vhost ab einer bestimmten Log file Größe automatisiert zu deaktivieren (sperren).

Re: crash - PHP Fehler /proc flooding

Posted: Sat 21. Jun 2025, 09:45
by Tobi
Also ich denke PHP bietet out of the box genügend Konfigurationsoptionen um das Verhalten des error logging zu beeinflussen. Bis hin zum kompletten Abschalten sämtlicher Meldungen.
Aktuell sehe ich jetzt keine Notwendigkeit diese Optionen in KeyHelp abzubilden.
Zumal wenn man den (vermeidbaren) Auslöser des Vorfalls berücksichtigt…

Last but not least möchte ich anmerken, dass du der erste User seit Bestehen von KeyHelp bist dem diese Einstellung auf die Füsse gefallen ist. Dies deutet zumindest darauf hin, dass es nur unter _sehr_ speziellen Rahmenbedingungen zu dem von dir gemeldeten Vorfall kommen kann.

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

Posted: Sat 21. Jun 2025, 10:16
by Ralph
Tobi wrote: Sat 21. Jun 2025, 09:45 Also ich denke PHP bietet out of the box genügend Konfigurationsoptionen um das Verhalten des error logging zu beeinflussen. Bis hin zum kompletten Abschalten sämtlicher Meldungen.
Aktuell sehe ich jetzt keine Notwendigkeit diese Optionen in KeyHelp abzubilden.
Zumal wenn man den (vermeidbaren) Auslöser des Vorfalls berücksichtigt…

Last but not least möchte ich anmerken, dass du der erste User seit Bestehen von KeyHelp bist dem diese Einstellung auf die Füsse gefallen ist. Dies deutet zumindest darauf hin, dass es nur unter _sehr_ speziellen Rahmenbedingungen zu dem von dir gemeldeten Vorfall kommen kann.
Das Problem kann und wird mit aktuellen oder mit veralteten Anwendungen auftreten und ist nichts neues (Forumsuche) auch Fail2ban kann während es mit einem 20GB log beschäftigt ist nicht mehr viel ausrichten was Attacken betrifft.
Das kann jeden treffen ... aber ich kann und werde es mir dann selber machen :mrgreen:

Re: crash - PHP Fehler /proc flooding

Posted: Sat 21. Jun 2025, 10:22
by Jolinar
Ralph wrote: Sat 21. Jun 2025, 10:16 aber ich kann und werde es mir dann selber machen :mrgreen:
:o :shock: :?

Re: crash - PHP Fehler /proc flooding

Posted: Sat 21. Jun 2025, 10:35
by Ralph
Jolinar wrote: Sat 21. Jun 2025, 10:22
Ralph wrote: Sat 21. Jun 2025, 10:16 aber ich kann und werde es mir dann selber machen :mrgreen:
:o :shock: :?
Haha, ja ich weiß ich bin ein dickköpfiger Querulant und das ist auch gut so (manchmal) :roll:

Re: crash - PHP Fehler /proc flooding

Posted: Sat 21. Jun 2025, 12:22
by Tobi
»Seid unbequem, seid Sand, nicht Öl im Getriebe der Welt«
Günter Eich

Alles gut Cowboy 🤠

Re: crash - PHP Fehler /proc flooding

Posted: Wed 25. Feb 2026, 17:13
by theqkash
Hallo zusammen,

ich hatte genau das gleiche Problem und möchte hier kurz dokumentieren, was die eigentliche Ursache war und wie man es auf Anwendungsebene beheben kann - vielleicht hilft es dem nächsten, der nach "Undefined offset XmlFileLoader.php line 582" sucht.

Was passiert ist: Nach dem Upgrade auf Ubuntu 24.04 ging ein PrestaShop 1.7.6.2 Shop von jetzt auf gleich nicht mehr. Im Error-Log tauchten massenhaft PHP Notice: Undefined offset in XmlFileLoader.php on line 582 auf - tausende pro Sekunde, die Logdatei wuchs in Minuten auf mehrere GB.

Die Ursache: Ubuntu 24.04 bringt eine neuere Version von libxml2 mit. Diese verarbeitet Whitespace im xsi:schemaLocation-Attribut von XML-Dateien anders als die Vorgängerversion. In Symfony 3.4 (auf dem PrestaShop 1.7.x aufbaut) gibt es in der Methode validateSchema() einen preg_split('/\s+/', $element), der die Namespace-URL-Paare aus dem Attribut liest. Die neue libxml2 liefert führende/nachfolgende Whitespace-Zeichen mit, wodurch leere Elemente im Array entstehen. Die Schleife erwartet aber immer Paare - und greift dann auf nicht existierende Array-Indizes zu. Ein einzelner Notice, der sich in einer Endlosschleife wiederholt und die Platte vollschreibt.

Fix - zwei Änderungen in einer Datei:

vendor/symfony/symfony/src/Symfony/Component/DependencyInjection/Loader/XmlFileLoader.php

1. In der Methode validateSchema() als erste Zeile return true; einfügen — das überspringt die XSD-Validierung komplett:

Code: Select all

  public function validateSchema(\DOMDocument $dom)
  {
      return true;
      // ... rest der Methode
  }
Die XSD-Validierung prüft nur, ob die XML-Dateien dem Schema entsprechen. Sie hat keinen Einfluss auf die Funktionalität. Die Dateien im vendor-Verzeichnis sind korrekt ausgeliefert.

2. Zusätzlich (als Absicherung, falls jemand den return-Workaround später entfernt) die preg_split-Zeile absichern. Vorher:

Code: Select all

  $items = preg_split('/\s+/', $element);
Nachher:

Code: Select all

  $items = preg_split('/\s+/', trim($element), -1, PREG_SPLIT_NO_EMPTY);
Danach Cache leeren und ggf. OPcache zurücksetzen.

Wichtig: Beide Änderungen liegen im vendor/-Verzeichnis und werden bei einem composer update überschrieben. Die eigentliche Lösung ist ein Upgrade auf eine aktuelle PrestaShop-Version mit aktuellem Symfony und PHP 8.x. PrestaShop 1.7.6 ist seit Jahren EOL und bekommt keine Sicherheitsupdates mehr.

Vielleicht erspart das jemandem ein paar Stunden Fehlersuche. :)