Probleme mit PHP 5.3 und dem Sitzungsordner


81

Ich habe kürzlich ein Upgrade auf PHP 5.3 durchgeführt und seitdem erhalte ich (sporadische) Fehlermeldungen, die darauf hinweisen, dass Apache (oder möglicherweise der Bereiniger der Sitzungsdateien) keine Berechtigungen für den Ordner hat, in dem die Sitzungen gespeichert sind.
Dies geschieht zufällig und kann nicht mit genauen Schritten reproduziert werden, was mich zu der Vermutung veranlasste, dass es sich um den Sitzungsreiniger handelt.
Hat jemand Erfahrung mit solchen Fehlern?

Die Fehlermeldung (die in der session_start()Leitung ausgelöst wird) lautet:

ps_files_cleanup_dir: opendir (/ var / lib / php5) fehlgeschlagen: Berechtigung verweigert.

ls -ltr im Sitzungsverzeichnis gibt an:

drwx-wx-wt  2 root          root          4096 2010-05-25 12:39 php5

In diesem Verzeichnis werden Sitzungsdateien von www-data angezeigt, bei denen es sich um meinen Apache handelt, und die App funktioniert einwandfrei. Was mich wundert, unter welchem ​​Benutzer der Sitzungs-GC ausgeführt wird?


Ich habe es getan, aber nicht am 5.3. Es stellte sich heraus, dass es sich um einen Berechtigungsfehler handelte, der auf den Speicherpfad der Sitzung heruntergefiltert wurde. Ich nehme an, Sie haben die Berechtigungen überprüft.
Jarrod Brennnesseln

@Jarrod Ich sehe, dass www-Daten in diesen Ordner lesen und schreiben können (der momentan für alle, Benutzer, Gruppe und Welt w & r ist). Soll ich etwas anderes überprüfen?
Itay Moav-Malimovka

Ich vermute, der Grund dafür ist, dass der Fehler sporadisch auftritt, wenn der Session Garbage Collector ausgeführt wird. Ich denke, dass die Wahrscheinlichkeit, dass er pro Sitzungsinitialisierung ausgeführt wird, standardmäßig 1% beträgt. Haben Sie Änderungen an php.ini in Bezug auf Sitzungen vorgenommen? Was liegt hier außerhalb der Standardeinstellung? Überprüfen Sie den Besitzer des Sitzungsordners. Danach bin ich ratlos, ohne die INI oder Fehler zu sehen.
Jarrod Brennnesseln

Der Besitzer ist root, die Sessions werden von www-data erstellt, jeder hat Zugriff auf diesen Ordner. Ich werde die INI-Einstellungen nacheinander durchgehen und nach etwas Verdächtigem suchen.
Itay Moav-Malimovka

ps_files_cleanup_dir: opendir (/ var / lib / php5) fehlgeschlagen: Berechtigung verweigert (
Itay Moav -Malimovka

Antworten:


121

Das Update: In Ihrem php.iniSet session.gc_probabilityzu0

Die Ursache, von der ich glaube, dass ich die Antwort hier gefunden habe http://somethingemporium.com/2007/06/obscure-error-with-php5-on-debian-ubuntu-session-phpini-garbage

Im Wesentlichen ist die Speicherbereinigung so eingerichtet, dass sie auf einigen Systemen (z. B. Ubuntu / Debian) von Cron-Jobs ausgeführt wird. Einige ausführbare PHP-INI-Dateien wie PHP-CLI versuchen ebenfalls, eine Speicherbereinigung durchzuführen, was zu dem Fehler führt, den Sie erhalten haben.


6
Ich habe dieses Problem auch unter Ubuntu 10.04, aber beim Überprüfen der php.ini fand ich session.gc_probabilitybereits eingestellt 0.
Jonathan

5
@ Jonathan - Sie werden wahrscheinlich feststellen, dass Ihre Anwendung den Wert dann festlegt.
SynackSA

3
@SynackSA Seltsamerweise wird beim Erstellen einer benutzerdefinierten, ortsspezifischen php.ini-Datei der session.gc_probabilityTrigger auf 1 gesetzt. Dies geschah auch dann, wenn in der php.ini-Datei überhaupt keine Einstellungen vorhanden sind ! Ich verwende suphp unter Ubuntu, Apache 2.2. Ich frage mich, ob das eine Art Fehler ist. Wie auch immer, das Hinzufügen session.gc_probability = 0zu meiner benutzerdefinierten, ortsspezifischen php.ini-Datei scheint das Problem zu beheben.
Jonathan

2
@ Jonathan Das ist die Art und Weise, wie es funktionieren soll, da der Standardwert 1 ist
ROunofF

2
Dadurch wird die Speicherbereinigung für Sitzungen deaktiviert. Sie sollten wahrscheinlich überprüfen wollen, ob tatsächlich ein Cron Ihre Sitzungen bereinigt.
Hansgoed

23

Dies scheint ein typischer Fehler auf Ubuntu-Servern zu sein (ich verwende Lucid LTS). Die Standardberechtigungen des Verzeichnisses / var / lib / php5 sind vorhanden

drwx-wx-wt  2 root     root     4096 2011-11-04 02:09 php5

Damit es vom Webserver geschrieben, aber nicht gelesen werden kann, erklärt dies vermutlich die Fehler.

Da Ubuntu über cron ( /etc/cron.d/php5) eine eigene Müllreinigung hat, ist es wahrscheinlich am besten, die Müllsammlung von php zu deaktivieren, wie oben von Diwant Vaidya vorgeschlagen.

session.gc_probability = 0

Es gibt tatsächlich einen Grund, warum der Sitzungsordner nicht weltweit lesbar sein sollte - wie im PHP-Handbuch angegeben :

Wenn Sie diesen Satz in einem weltweit lesbaren Verzeichnis belassen, z. B. / tmp (Standardeinstellung), können andere Benutzer auf dem Server möglicherweise Sitzungen entführen, indem sie die Liste der Dateien in diesem Verzeichnis abrufen.


2

Die Lösung, die ich derzeit verwende (von der ich nicht sicher bin, ob sie die richtige ist), besteht darin, dem Apache-Benutzer (in meinem Fall www-Daten) den Besitz des Sitzungsordners zu übertragen.


2
Wie Marie oben erwähnt hat, kann dies zu einem Sicherheitsproblem für jeden Produktionsserver führen.
Kzqai

2
Ich habe längst die richtige Lösung implementiert :-) Aber das Sicherheitsproblem liegt hauptsächlich bei gemeinsam genutzten Servern
Itay Moav -Malimovka

1
@pike Session Reinigung wird von PHP CLI über CRON
Itay Moav -Malimovka

1

Dieses Problem nervt mich schon eine Weile. Ich habe den Wert wie in php.ini vorgeschlagen geändert und das Problem trat immer wieder auf. Ich habe den gleichen Konfigurationswert in meiner index.php und auch in private / Zend / session.php gefunden. Es lohnt sich also, etwas genauer hinzuschauen, wenn das Problem weiterhin auftritt. Ich hoffe das ist nützlich für jemanden.

Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.