Korrekter Ordner für PHP-Sessions (ps_files_cleanup_dir: Permission denied)

[Cangooou User Alle Beiträge durchsuchen Profil ansehen Schließen Cangooou]

Hallo!

Sowohl bei unseren beiden Managed Server als auch im Webhosting ist standardmäßig session.save_path auf /tmp gesetzt. Dies erzeugt aber im error_log regelmäßig die Meldung:
Notice: session_start(): ps_files_cleanup_dir: opendir(/tmp) failed: Permission denied (13)

Es scheint aber (bisher) keine Auswirkungen auf den Betrieb zu haben. Sollte ich trotzdem für session.save_path lieber einen eigenen Pfad angeben?

[Cangooou User Alle Beiträge durchsuchen Profil ansehen Schließen Cangooou]

Ah, ich habe gerade das hier gefunden: https://www.df.eu/de/support/df-faq/...hen/php/#c1408

[Nils Dornblut Kundenservice Alle Beiträge durchsuchen Profil ansehen Schließen Nils Dornblut]

Ah, ich habe gerade das hier gefunden: https://www.df.eu/de/support/df-faq/...hen/php/#c1408

Genau, hier ist das erklärt

Mit freundlichen Grüßen

Nils Dornblut

[Cangooou User Alle Beiträge durchsuchen Profil ansehen Schließen Cangooou]

Damit ich das richtig verstehe: Im Prinzip wird dadurch der garbage collector von php, der die Session-Files aufräumt, aus Sicherheitsgründen geblockt, aber es wird ein eigener Mechanismus verwendet, der die Session-Files aufräumt? Hält sich dieser auch z.B. an session.gc_maxlifetime, session.gc_divisor und session.gc_probability?

Hintergrund ist, dass wir gerade schauen, ob wir eine eigene Session-Verwaltung bauen, um das Blocken der php-session im php eigenen Handler zu umgehen.

[Marcel Kaufmann Kundenservice Alle Beiträge durchsuchen Profil ansehen Schließen Marcel Kaufmann]

Hallo Cangooou,

Damit ich das richtig verstehe: Im Prinzip wird dadurch der garbage collector von php, der die Session-Files aufräumt, aus Sicherheitsgründen geblockt, aber es wird ein eigener Mechanismus verwendet, der die Session-Files aufräumt? Hält sich dieser auch z.B. an session.gc_maxlifetime, session.gc_divisor und session.gc_probability?

Hintergrund ist, dass wir gerade schauen, ob wir eine eigene Session-Verwaltung bauen, um das Blocken der php-session im php eigenen Handler zu umgehen.

Der Prozess, welcher die Daten innerhalb des /tmp-Ordners bereinigt, prüft in unserer Voreinstellung die Lebensdauer der vorhandenen temporären Dateien. Haben diese eine Lebensdauer von >= 24 Stunden erreicht, werden diese durch den Prozess automatisch gelöscht. Dadurch, dass die Lebensdauer mit 24h relativ hoch angesetzt ist, kann es dazu führen dass dieser Prozess hunderttausende bis Millionen an Dateien prüfen und ggf. löschen muss. Dies kann dann im schlimmsten Fall zu Überlastungen führen.

Um dieses Verhalten zu optimieren, können Sie selbst die Kontrolle über diesen sogenannten "GarbageCollector" übernehmen. Hierzu editieren Sie bitte im Kundenmenü die PHP.INI der Domain bzw. des Auftrags. Unterhalb der "häufig genutzten Optionen" finden sich nun einige Parameter "session.", ändern Sie hier bitte zuerst den Wert von 'session.save_path' auf ein Verzeichnis innerhalb Ihres Webspace (z.B. /temp) ab.

Beispiel:

alt: 'session.save_path = /tmp'

neu: 'session.save_path = /kunden/12345_85737/temp'

Wenn Sie den 'session.save_path' auf ein Verzeichnis innerhalb Ihres Webspace gelegt haben, können Sie nun auch den GarbageCollector konfigurieren. Über den Parameter "session.gc_maxlifetime" können Sie einstellen wie lange die Lebensdauer einer Datei sein soll, bevor diese automatisch gelöscht wird. Bitte stellen Sie hier einen kleineren Wert als die bislang genutzten 24 Stunden ein, dadurch wird die Last beim Prüfen&Löschen der Dateien deutlich minimiert. Bei einer Lebensdauer von 12 Stunden kann man beispielsweise bereits von ~50% weniger Last ausgehen. Desweiteren können Sie auch noch die folgenden Werte anpassen, "session.gc_probability/session.gc_divisor" und "session.cache_expire" müsste dabei einfach im PHP.INI-Editor unten unter "Sonstige Einstellungen" in den [PHP]-Block eingetragen werden:

- session.gc_probability/session.gc_divisor
session.gc_divisor definiert gekoppelt mit session.gc_probability die Wahrscheinlichkeit, mit der die gc (garbage collection, bezeichnet die Löschung nicht mehr aktiver Sessions) Routine bei jeder Initialisierung einer Session gestartet wird. Die Wahrscheinlichkeit errechnet sich aus gc_probability/gc_divisor.

- session.cookie_lifetime
Bezeichnet die maximale Laufzeit eines Cookies. Der Wert "0" bedeutet, dass der Cookie eine unbegrenzte Laufzeit besitzt.

Nicht zwingend zu ändern ist folgender Parameter:

- session.cache_expire
Spezifiziert in Minuten, wie lange Session-Seiten im Cache bleiben. Sofern session.cache_limiter auf "nocache" steht, ist diese Angabe wirkungslos.


Weitere Informationen und Einstellmöglichkeiten zum Session-Handling können Sie auch unter folgendem Link einsehen:

http://php.net/manual/de/session.configuration.php

[Cangooou User Alle Beiträge durchsuchen Profil ansehen Schließen Cangooou]

Vielen Dank für die Klarstellung. Eigentlich ist die Vermeidung einer Auflistung der Session-Dateien in tmp/ ja durchaus sinnvoll, daher hätte ich das natürlich gerne genutzt.

Das Problem mit einer Lebenszeit <= 24h (egal ob in tmp oder einem eigenen Ordner) ist, dass in den Session-Dateien ja üblicherweise auch User-Sessions gespeichert werden, z.B. von eingeloggten Endkunden in einem Shop oder Benutzer in einem Forum. Nun geht ein End-Benutzer aber davon aus, dass er z.B. nach einem Einloggen und Anklicken von "Angemeldet bleiben" länger als 1 Tag angemeldet bleibt. Was schlagen Sie hierzu vor? Sollte man dann die Session-Daten gleich komplett in die Datenbank verlegen?

[Nils Dornblut Kundenservice Alle Beiträge durchsuchen Profil ansehen Schließen Nils Dornblut]

Das Problem mit einer Lebenszeit <= 24h (egal ob in tmp oder einem eigenen Ordner) ist, dass in den Session-Dateien ja üblicherweise auch User-Sessions gespeichert werden, z.B. von eingeloggten Endkunden in einem Shop oder Benutzer in einem Forum. Nun geht ein End-Benutzer aber davon aus, dass er z.B. nach einem Einloggen und Anklicken von "Angemeldet bleiben" länger als 1 Tag angemeldet bleibt. Was schlagen Sie hierzu vor? Sollte man dann die Session-Daten gleich komplett in die Datenbank verlegen?

Was für eine Empfehlung möchten Sie hier haben? Wie lange eine Session Gültigkeit hat, können Sie ja entsprechend konfigurieren/programmieren. Wenn dazu etwas im tmp-Ordner vorhanden sein muss, stellt sich die Frage nicht, aber ich denke man kann von der Architektur her das doch sehr wohl entkoppeln. Falls es da einen konkreten Zusammenhang gibt, bitte gerne beschreiben, dann kann man das Problem genauer diskutieren.

Ggf. wird Herr Kaufmann seine Gedanken hier noch anfügen, falls ich was übersehen habe.

Mit freundlichen Grüßen

Nils Dornblut

[Cangooou User Alle Beiträge durchsuchen Profil ansehen Schließen Cangooou]

Ok, ganz konkret: Wenn ich in PHP session.gc_maxlifetime auf 30 Tage setze und die Session-Files im vorgegebenen /tmp-Ordner belasse, würden die Session-Files trotzdem von der DF-eigenen Garbage-Collection nach 24h gelöscht. Richtig?

[masterframe Reseller Alle Beiträge durchsuchen Profil ansehen Schließen masterframe]

Ok, ganz konkret: Wenn ich in PHP session.gc_maxlifetime auf 30 Tage setze und die Session-Files im vorgegebenen /tmp-Ordner belasse, würden die Session-Files trotzdem von der DF-eigenen Garbage-Collection nach 24h gelöscht. Richtig?

Korrekt.