[3.3] Einloggen nicht möglich - sessions > 7.000 Einträge

[db1982]

Hallo,

manchmal ist binnen Stunden, manchmal auch nach Wochen die phpbb_sessions mit über 7.000 Einträgen (genauer gesagt meist 7.125) gefüllt. Dann ist kein Einloggen mehr möglich und es kommt der Fehler "Das übermittelte Formular ungültig. Versuchen Sie erneut, das Formular abzusenden". Wenn ich über phpmyadmin die phpbb_sessions leere klappt es wieder, bis sie wieder "voll" ist.
Wie kann ich dem vorbeugen bzw. was muss ggf. geändert werden?

Danke!

[LukeWCS]

Hallo

Am Rande: Das Löschen der Sessions kannst du auch im ACP -> ALLGEMEIN -> Sitzungsdaten löschen.

Was hast du den unter ACP -> ALLGEMEIN -> Serverlast -> Sitzungslänge: eingetragen?

Unabhängig davon können solche massiven Zugriffe entstehen, wenn ein Spambot versucht massenhaft Accounts zu registrieren oder aber PWs durchprobiert. Allgemein wäre mal interessant die Access Logs der letzten Tage zu sichten, welche Seite/Funktion da massenhaft angesteuert wird. Das kann dabei helfen mal einzuschätzen, was da im Gange ist.

edit: Mein erster Hinweis bringt halt nicht so wirklich viel, wenn Login nicht mehr geht. Okay, war ein langer Tag.

[HJW]

Hallo,

wie neu ist deine .htaccess? Bei mir gab es das Problem weil ich die, bei einem Update, immer unverändert übernommen habe.
Da fehlte dann diese Abschnitt:

Code: Alles auswählen

# Apache content negotation tries to interpret non-existent paths as files if
# MultiViews is enabled. This will however cause issues with paths containg
# dots, e.g. for the cron tasks
<IfModule mod_negotiation.c>
	Options -MultiViews
</IfModule>

und führte genau zu dem beschriebenen Problem.

[db1982]

Hallo zusammen,

zunächst danke für eure Antworten.

In der htaccess ist diese Passage drin - das kann also nicht das Problem sein - danke trotzdem!

Als Sitzungslänge sind 3600 Sekunden eingestellt. Ist das evtl. zu viel oder zu wenig?

Wo finde ich die Logdateien?

Danke vorab!

[Mike-on-Tour]

Die Sitzungslänge passt, nach meiner Erinnerung ist 3600 (Sekunden), also eine Stunde, der voreingestellte Wert.

Aber vielleicht läuft der Cron-Task zum Löschen der SESSIONS_TABLE nicht korrekt. Lasse doch mal in phpMyAdmin folgende Abfrage laufen:

Code: Alles auswählen

SELECT * FROM `phpbb_config` WHERE config_name LIKE '%gc%';

Und dann schaue mal, welche Werte bei session_gc und session_last_gc steht.
Beim ersten sollte "3600" stehen und beim zweiten ein zehnstelliger Wert, der mit "167" anfängt.
Wenn das nicht der Fall ist, stimmt was mit dem Cron-Task nicht.

[db1982]

Hallo,

danke für die Rückmeldung.

Bei session_gc steht 3600 - bei sessions_last_gc steht 1678281818

Bei is_dynamic steht bei session_gc 0 und bei session_last_gc 1 - hat das ggf. damit etwas zu tun?

Danke!

[Mike-on-Tour]

Nein, das muss so, diese beiden Einstellungen sind so korrekt.

Und gemäß dem Datum-Zeit-Stempel lief der Cron-Task zuletzt am 08.03.2023 um 14:23 Uhr. Dazu muss man aber wissen, dass nur beim Aufruf des Forums geprüft wird, ob die eingestellte Zeitspanne seit dem letzten Lauf abgelaufen ist und bei positivem Ergebnis der Lauf erneut gestartet wird. Alle 3600 Sekunden würde er theoretisch also nur laufen, wenn sich andauernd jemand in das Forum einloggt.
Eigentlich müsste deine SESSIONS_TABLE also leer sein. Könnte natürlich sein, dass der Cron-Task länger laufen würde als die eingestellte Laufzeit für PHP-Skripte. Was steht denn in der PHP-Konfigurations-Variablen max_execution_time? Diese kannst du über den Link "PHP-Information" im ACP-Reiter "Allgemein" auslesen.

Ansonsten würde ich mal dem schon erteilten Ratschlag folgen und die Tabelle manuell über den ACP leeren. Dann hast du erstmal wieder Ruhe und kannst die Ursache entspannt suchen.

[db1982]

Hallo,

da steht bei beiden Werten 30.

Müsste da 3600 stehen?

[Scanialady]

Nein. 30 ist die normale Einstellung - es geht hier um die Zeit, die für ein Script als Laufzeit zur Verfügung steht. Es ist eine Servereinstellung.

[db1982]

Ok, danke für die vielen Infos.

Was ist also wohl noch falsch? Ich bin jetzt etwas ratlos.