Skip to main content

🗄️ Session-Probleme?

MODX: Session-Status korrekt prüfen (PHP-GC & DB-Sessions)

🔍 Überblick

MODX registriert keinen eigenen PHP-Session-Handler. Es nutzt die von PHP bereitgestellten Sessions zur Identifikation, speichert MODX-spezifische Sitzungsdaten jedoch in der eigenen Datenbanktabelle modx_session. Die PHP-Garbage-Collection bleibt unverändert, während MODX seine Session-Daten separat bereinigt.

Standard-Beispiel:

  • Tabelle: modx_session

Hinweis:

  • Das Tabellen-Prefix ist installationsabhängig
  • In allen folgenden Beispielen wird durchgehend modx_ verwendet

Wichtig:

  • PHP Session-Garbage-Collection (GC) betrifft nur PHP-Sessions
  • Die MODX DB-Sessiontabelle wird davon nicht automatisch bereinigt

🧪 1) PHP Session-GC über phpinfo prüfen

In einer phpinfo()-Ausgabe den Abschnitt session aufrufen.

Relevante Einstellungen:

  • session.gc_probability
  • session.gc_divisor
  • session.gc_maxlifetime
  • session.save_handler

📌 Interpretation

  • gc_probability / gc_divisor
    Beispiel: 1 / 1000 → 0,1 % Chance pro Request (normal)

  • gc_maxlifetime
    Zeit in Sekunden, nach der Sessions als abgelaufen gelten

  • save_handler

    • files → PHP-GC räumt File-Sessions selbst auf
    • user / redis / memcached → Cleanup abhängig vom Handler

⚠️ Wichtig:

  • Immer den Local Value beachten, nicht den Master Value
  • PHP-GC betrifft keine MODX DB-Sessions
  • Bei session.save_handler = user hängt der Cleanup vom Handler ab

🗄️ 2) MODX DB-Sessiontabelle prüfen

MODX speichert seine Sitzungsdaten in der Datenbank.

🔧 Nützliche SQL-Abfragen

  • Anzahl der Sessions:

    SELECT COUNT(*) FROM modx_session;

  • Älteste und neueste Session:

    SELECT
  MIN(`access`) AS oldest,
  MAX(`access`) AS newest
FROM modx_session;

  • Optional: lesbare Datumswerte:

    SELECT
  FROM_UNIXTIME(MIN(`access`)) AS oldest,
  FROM_UNIXTIME(MAX(`access`)) AS newest
FROM modx_session;

  • Sehr alte Sessions (z.B. älter als 30 Tage):

    SELECT COUNT(*)
FROM modx_session
WHERE `access` < UNIX_TIMESTAMP() - (30 * 86400);

📊 3) Einordnung

  • Eine wachsende Session-Tabelle ist meist normal
  • PHP-GC räumt keine DB-Sessions auf
  • MODX räumt DB-Sessions bewusst nicht aggressiv auf
  • Die Größe der DB-Sessiontabelle allein ist kein Fehlerindikator

🧠 Fazit

Session-Probleme entstehen selten durch fehlenden PHP-GC, sondern durch handlerabhängiges Session-Cleanup (session.save_handler = user) und riskante Eingriffe in die MODX DB-Sessiontabelle.

Prüfen, verstehen, beobachten – nicht blind löschen.

📎 Anhang (ohne Gewähr, vorher Backup erstellen)

Wenn MODX stabil läuft, ist das manuelle Löschen sehr alter DB-Sessions normalerweise nicht notwendig.
Eine wachsende modx_session-Tabelle ist für sich genommen kein Fehler.
Session-Cleanup ist eine Sondermaßnahme, z.B. nach Migrationen, Fehlkonfigurationen oder bei konkreten Problemen.

Sehr alte MODX DB-Sessions löschen
(z.B. älter als 30 Tage)

  1. Zuerst prüfen, wie viele Datensätze betroffen wären:
SELECT COUNT(*) AS to_delete
FROM modx_session
WHERE `access` < UNIX_TIMESTAMP() - (30 * 86400);

Optional: älteste und neueste Session lesbar anzeigen:

SELECT
  FROM_UNIXTIME(MIN(`access`)) AS oldest,
  FROM_UNIXTIME(MAX(`access`)) AS newest
FROM modx_session;
  1. Alte Sessions löschen (einmalig):
DELETE FROM modx_session
WHERE `access` < UNIX_TIMESTAMP() - (30 * 86400);
  1. Bei sehr großen Tabellen: besser in Batches löschen
    (mehrfach ausführen, reduziert Locks):
DELETE FROM modx_session
WHERE `access` < UNIX_TIMESTAMP() - (30 * 86400)
LIMIT 5000;
Back to top