[3.3] Sporadische php-Fehler

[vfrblue]

Man könnte jetzt die Tabellen auf die gleiche Kollation ändern wie die Server-Verbindung und den Typ auf InnoDB, aber ob dadurch der Fehler verschwindet, wage ich zu bezweifeln.

Mir ging es darum, ob die Kollation vielleicht noch "utf8-bin" ist, da php8.x ein wenig "störrisch" mit dem Zeichensatz umgeht.

Edit(h):
Diese sporadischen Fehlermeldungen kenne ich auch. Ich habe festgestellt, daß diese vermehrt auftraten, wenn das Webspace von Bots "überschwemmt" wurde und dadurch der Zugriff auf die DB kurz vor der maximalen Zulässigkeit war.
Ein konsequentes Sperren von Zugriffen aus Fernost und Osteuropa (RU, etc) und Aktualisierung auf MariaDB 10.11.x hat bis jetzt zu keinen Fehler mehr geführt.

[LukeWCS]

Gerade eben noch das hier gefunden, was sehr genau zu dem Problem hier passen würde:

https://www.phpbb.com/community/viewtopic.php?t=2642101

Da war von Styles die Rede aber leider keine Info, ob es das wirklich war und ob das Problem inzwischen gelöst wurde. Aber aufgrund meiner Code Recherche wo ich die Fehlermeldungen ala Schnitzeljagd rückwärts verfolgt habe und dabei in session.php gelandet bin, kann ich mir nicht wirklich vorstellen, dass ein veralteter Style eine solche Situation verursachen könnte, dass die DB schlicht gar nicht reagiert. Des Weiteren haben wir hier ja die Styles auch schon ausgeklammert, denn auch mit prosilver tritt das Problem auf.

Da ist aktuell vfrblues Aussage (edit) schon erheblich einleuchtender/nachvollziehbarer.

[guenniguenzelsen]

Man könnte jetzt die Tabellen auf die gleiche Kollation ändern wie die Server-Verbindung und den Typ auf InnoDB, aber ob dadurch der Fehler verschwindet, wage ich zu bezweifeln.

Mir ging es darum, ob die Kollation vielleicht noch "utf8-bin" ist, da php8.x ein wenig "störrisch" mit dem Zeichensatz umgeht.

Soeben erledigt
Alles auf InnoDB und utf8mb4_unicode_ci umgestellt

Edit(h):
Diese sporadischen Fehlermeldungen kenne ich auch. Ich habe festgestellt, daß diese vermehrt auftraten, wenn das Webspace von Bots "überschwemmt" wurde und dadurch der Zugriff auf die DB kurz vor der maximalen Zulässigkeit war.
Ein konsequentes Sperren von Zugriffen aus Fernost und Osteuropa (RU, etc) und Aktualisierung auf MariaDB 10.11.x hat bis jetzt zu keinen Fehler mehr geführt.

Ich habe hier vor einer Weile per Cloudflare die Zugriffe aus ganzen Regionen unterbunden.
Seitdem sind tatsächlich immer nur eine handvoll User online.
Das Problem existierte aber unabhängig davon schon zuvor.
MariaDB 10.6.19 ist das aktuellste, was mein Provider anbietet.

Gerade eben noch das hier gefunden, was sehr genau zu dem Problem hier passen würde:

https://www.phpbb.com/community/viewtopic.php?t=2642101

Da war von Styles die Rede aber leider keine Info, ob es das wirklich war und ob das Problem inzwischen gelöst wurde. Aber aufgrund meiner Code Recherche wo ich die Fehlermeldungen ala Schnitzeljagd rückwärts verfolgt habe und dabei in session.php gelandet bin, kann ich mir nicht wirklich vorstellen, dass ein veralteter Style eine solche Situation verursachen könnte, dass die DB schlicht gar nicht reagiert. Des Weiteren haben wir hier ja die Styles auch schon ausgeklammert, denn auch mit prosilver tritt das Problem auf.

Den veralteten Prosilver Dark habe ich letztes Jahr schon rausgeworfen.
Aktuell ist ausschließlich der Standard Prosilver installiert.


Ich gebe morgen früh wieder Bescheid, ob die Datenbankumstellung etwas verändert hat.

Danke Euch beiden!

[guenniguenzelsen]

Der Erfolg blieb leider aus.
Ich habe von 0:00 Uhr bis 9:30 Uhr wieder 16 dieser Fehlermeldungen im Error-Log.

[Scanialady]

Ich frage mich, ob nicht einfach der Datenbankserver überlastet ist, und ständig Aussetzer hat. Vielleicht solltest du doch über einen Umzug nachdenken. Mit dem Test über eine zweite Datenbank hast du ja nun schon mal dafür geübt.

[LukeWCS]

@Lady

Der gestrige Fund von dir mit dem Apache Fehlercode würde exakt zu dem von guenniguenzelsen passen. Und die Beschreibung zum Fehlercode würde wiederum zu dem passen, was vfrblue geschrieben hat.

Kein klares Muster
- Meistens läuft alles ohne Fehler.
- Manchmal tauchen die Fehlermeldungen innerhalb des Headers der Startseite auf.
- Selten wird die Startseite nicht geladen und es werden nur die php-Fehler gezeigt.

Der Hintergrund meiner Frage war, herauszufinden ob es immer nur an einer bestimmten Stelle hakt. Dem ist leider nicht so; nach deiner Auflistung hier, kann das an mehreren Stellen auftreten.

Denkbar wäre nämlich, dass man erstmal einen Workaround einbaut, der nicht gleich beim ersten Mal aufgibt, sondern den Zugriff auf die DB nach 1 Sekunde nochmal wiederholt und erst wenn z.B. 5 Versuche fehlschlagen, dann eine kontrollierte Fehlermeldung ausgegeben wird. Durch meine Fehler-Schnitzeljagd hätte ich dafür schon die passende Stelle ausfindig gemacht. Aber das wäre eben nur EINE Stelle, wäre aber trotzdem mal einen Versuch wert.

Aber erstmal Begrifflichkeiten klären: Was verstehst du unter "Startseite"? Weil das ist für uns eigentlich das, was man im ACP unter "Board-Einstellungen -> URL der Homepage:" einstellen kann. Aber ich vermute mal, du meinst wohl eher die Foren-Übersicht (Index).

[guenniguenzelsen]

Denkbar wäre nämlich, dass man erstmal einen Workaround einbaut, der nicht gleich beim ersten Mal aufgibt, sondern den Zugriff auf die DB nach 1 Sekunde nochmal wiederholt und erst wenn z.B. 5 Versuche fehlschlagen, dann eine kontrollierte Fehlermeldung ausgegeben wird. Durch meine Fehler-Schnitzeljagd hätte ich dafür schon die passende Stelle ausfindig gemacht. Aber das wäre eben nur EINE Stelle, wäre aber trotzdem mal einen Versuch wert.

Aber erstmal Begrifflichkeiten klären: Was verstehst du unter "Startseite"? Weil das ist für uns eigentlich das, was man im ACP unter "Board-Einstellungen -> URL der Homepage:" einstellen kann. Aber ich vermute mal, du meinst wohl eher die Foren-Übersicht (Index).

Wenn Du eine Idee hast, wie man dem Fehler weiter auf die Spur kommen kann, dann baue ich was immer notwendig ist ein und erstatte Bericht

Mit Startseite meinte ich tatsächlich die Foren-Übersicht.
Wobei ich das fairerweise garnicht mit Sicherheit auf die Forenübersichtsseite beschränken kann.

[LukeWCS]

Dann ist das geklärt.

Wobei ich das fairerweise garnicht mit Sicherheit auf die Forenübersichtsseite beschränken kann.

Jupp, laut deinen Rückmeldungen ist das eher nicht auf die Foren-Übersicht begrenzt.

Okay, ich baue und teste bei mir mal einen Workaround und Debug Code, das kann aber etwas dauern.

[LukeWCS]

Bevor ich dir Debug-Code zum Einbauen gebe, hätte ich gerne einen aktuellen File Check Bericht. Das Tool bitte ausführen und Bericht hier posten:

phpBB File Check - Zum prüfen auf Existenz und Intaktheit der phpBB Dateien

[guenniguenzelsen]

Anbei das Ergebis, wie gewünscht:

Code: Alles auswählen

phpBB File Check v1.4.3
=======================

Version mode : Auto
MD5 source   : ZIP (1, 2, E)
phpBB Version: 3.3.13
MD5 Version 1: 3.3.13 (phpBB.com)
MD5 Version 2: 3.3.13 (phpBB.de)
PHP Version  : 8.3.10 (Linux)

Please wait, 4075 checksums are being processed...

----------------------------------------------------------------------------------------------------------
{2:  84} * CHANGED: [language/de/email/user_forgot_password.txt] (hash: 72f62e87f4d355c0f6bc785ce526fad6)
{2:  88} * CHANGED: [language/de/email/user_welcome.txt] (hash: c092ff22b29f41846db060adebd0105f)
{2:  89} * CHANGED: [language/de/email/user_welcome_inactive.txt] (hash: 77122f839f95b1718b85bc77f9a3752b)
{1:1641} * CHANGED: [styles/prosilver/theme/colours.css] (hash: 4d2d98c8e7d0488dbfd5973e5a22bf12)
{1:1642} * CHANGED: [styles/prosilver/theme/common.css] (hash: 5534eb6dd3afb5b0f8b79f2c04b7e97e)
{2: 210}   NOTICE : [vendor/composer/installed.php] has the phpBB.de hash
----------------------------------------------------------------------------------------------------------

Finished!

Report summary
-------------------
Checked files: 3947
Missing files:    0
Changed files:    5
Notices      :    1

Script/PHP information
----------------------------------------------------------------------
Run time          : 0.203 seconds
Max execution time: 60 seconds
Memory peak usage : 4,167,208 bytes
Memory limit      : 128M
Services          : ZipArchive:1, cURL:1, Sockets:1, allow_url_fopen:1