2015-12-06 4 views
16

Ich kompilierte php7 selbst (974f6c2a705). wenn ich php7 + php-fpm + nginx mit symfony laufen bekomme ich diesen Fehler:PHP7 + Symfony 2.8, Sitzungsdaten konnten nicht geschrieben werden

(die snc redis für Sitzungen bündeln mit :)

Warning: session_write_close(): Failed to write session data (user). Please verify that the current setting of session.save_path is correct (/tmp) 

(die native Unterstützung von Sitzungen mit :)

Warning: session_write_close(): Failed to write session data (user). Please verify that the current setting of session.save_path is correct (/[...]/app/cache/dev/sessions) 

das Problem scheint Symfony verwandt zu sein, weil PHP Lese-/Schreibzugriff auf den Ordner hat.

, wenn ich nichts anderes als diesen Code ausführen, funktioniert es:

session_start(); 
$_SESSION['x'] = 4234; 
session_write_close(); 

Anregungen oder Ideen, warum symfony die Sitzungen schreiben versagt?

+0

Ist es der gleiche 'session.save_path' für PHP7 und PHP5? – Andrea

+0

haha ​​... Ich habe einen ähnlichen Fehler für PHP7 .. Ich benutze einen benutzerdefinierten Session-Handler, aber bekomme auch diesen Fehler "session_write_close(): Sitzung Rückruf erwartet True/False Rückgabewert" – Clay

+0

In meinem Fall musste ich zurückkehren true/false in meinem benutzerdefinierten Session-Save-Handler anstelle von "return" (keine Überraschung dort ....) – Clay

Antwort

9

PHP7 ist strenger mit der Sitzungsbehandlung für benutzerdefinierte Session-Handler. Der benutzerdefinierte Session-Handler von Symfony für seine Schreibmethode gibt aus irgendeinem Grund den Wert false zurück. Zuvor hat dies keinen Fehler ausgelöst, aber jetzt tut es das.

Da wir nicht viele Informationen darüber haben, welchen benutzerdefinierten Sitzungshandler Sie verwenden, würde ich vorschlagen, einen anderen benutzerdefinierten Sitzungshandler zu setzen, wenn möglich, da die meisten von ihnen scheinbar wahr sind.

Hier sind die verschiedenen Session-Handler Symfony, erscheinen die meisten von ihnen ausdrücklich true zurück, mit Ausnahme der Memcache Einsen und WriteCheckSessionHandler:

https://github.com/symfony/symfony/tree/582f4753a343f230fbe18b4e9a0747d48351ddfb/src/Symfony/Component/HttpFoundation/Session/Storage/Handler

EDIT:

Da Sie das Snc Redis Bundle erwähnen Session-Handler, sind Sie sicher, dass Sie die aktuellste Version verwenden? Vor einem Jahr wurde es geändert, um immer true zurück auf Schreib:

https://github.com/snc/SncRedisBundle/blob/master/Session/Storage/Handler/RedisSessionHandler.php

UPDATE

einen Fehler zu PHP eingereicht, um zu sehen, ob wir eine nützlichere Fehlermeldung für zukünftige Versionen herausfinden können (bitte wählen oder einen Kommentar über den Bug-Report) verlassen:

https://bugs.php.net/bug.php?id=71070

+2

Ich zog nach dev-Master (Snc Redis Bundle) und es funktioniert. Danke. – timg

+1

Ich musste True zurückgeben für "zerstören" und "GC" Methoden auch. – kodvin

2

Glad Ihr Problem zu sehen ist gelöst - nur anot hinzufügen wollten Ihre Anmerkung zur Klarheit, wenn jemand, der diese Fehler erhält, über diesen Thread stolpert: Die Fehler haben offensichtlich mit einem Problem im Framework-Treiber und/oder seiner Konfiguration begonnen, und deshalb hat das Aktualisieren auf den letzten Zweig das Problem gelöst. Die Fehlermeldung selbst ist aufgetreten, weil PHP versucht hat, den Symfony Redis-Sitzungstreiber zu verwenden, und aufgrund von Problemen mit der Konfiguration zum sess.save_path in php.ini zurückgekehrt ist. Dies ist der Grund, warum PHP nicht in das Verzeichnis schreiben konnte - es versuchte den Benutzer save_handler (Redis) mit dem php.ini sess.save_path (Dateien) zu verwenden. Wenn es auf die Standardeinstellungen zurückfällt, sollte es auch die Einstellung php.ini sess.save_handler verwenden. Wie auch immer, der Fehler selbst weist in diesem Fall nicht auf das eigentliche Problem hin.

4

Wenn Sie diesen Thread gefunden haben, weil die Fehlermeldung in einigen Suchergebnissen oben in der Liste erscheint und nicht Symphony verwendet - was in meinem Fall passiert ist.Stellen Sie sicher, dass die Schreibmethode des Sitzungshandlers bool - true on success zurückgibt.

Die php Dokumentation erwähnt dies nicht. Es ist jedoch in der SessionHandlerInterface Dokumentation erwähnt:

The return value (usually TRUE on success, FALSE on failure). Note this value is returned internally to PHP for processing.

In früheren Versionen von PHP, nichts Rückkehr nicht zu einem Fehler geführt hat. Seit PHP 7.0 führt die Rückgabe von nichts zu dem Fehler: Warning: session_write_close(): Failed to write session data (user). Please verify that the current setting of session.save_path is correct (/tmp).

Es sieht so aus, als ob zukünftige Versionen von PHP die etwas klarere Nachricht ausgeben werden. Failed to write session data using user defined save handler.

Wenn Sie Symphony verwenden - dann bietet die Antwort von Chris Banks eine vollständigere und nützlichere Lösung für das ursprüngliche Problem.

0

Ich hatte das gleiche Problem, als ich von Apache PHP7 zu PHP7-FPM wechselte. Nur beheben für mich war es, in das var-Verzeichnis meiner Symfony-App zu gehen und alle Dateien dort zu entfernen, die Berechtigungen für die var bei Bedarf chmod 777 zu beheben. Danach laden Sie die URL meiner App und gut zu gehen. Anschließend wird Symfony alle Cache, Protokolle, Sitzungen usw. neu erstellen.

Verwandte Themen