PHP7 + Symfony 2.8, échec de l'écriture des données de session
j'ai compilé php7 moi-même (974f6c2a705). si j'exécute php7 + php-fpm + nginx en utilisant symfony je reçois cette erreur:
(à l'aide de la snc redis bundle pour les sessions:)
Warning: session_write_close(): Failed to write session data (user). Please verify that the current setting of session.save_path is correct (/tmp)
(en utilisant le natif de soutien de session:)
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)
le problème semble lié à symfony, parce que php a accès en lecture / écriture au dossier.
si je lance, mais rien de ce code, il fonctionne:
session_start();
$_SESSION['x'] = 4234;
session_write_close();
n'importe quelles suggestions ou idées pourquoi symfony ne parvient pas à écrire les sessions?
4 réponses
PHP7 est plus strict avec la manipulation de session pour les gestionnaires de session personnalisés. Le gestionnaire de session personnalisé de Symfony pour sa méthode d'écriture est, pour quelque raison que ce soit, de retourner false. Auparavant, cela ne déclenchait pas d'erreur, mais maintenant si.
étant donné que nous n'avons pas beaucoup d'informations sur le gestionnaire de session personnalisé que vous utilisez, je suggère de configurer un gestionnaire de session personnalisé différent si possible puisque la plupart d'entre eux semblent retourner true.
Voici les différents les gestionnaires de session Symfony, la plupart d'entre eux semblent explicitement retourner true sauf pour ceux de Memcache et WriteCheckSessionHandler:
EDIT:
puisque vous mentionnez le gestionnaire de session paquet Redis de Snc, êtes-vous sûr d'utiliser la version la plus récente? Il y a un an il a été modifié pour toujours retour véritable à écrire:
https://github.com/snc/SncRedisBundle/blob/master/Session/Storage/Handler/RedisSessionHandler.php
UPDATE
a soumis un bug à PHP pour voir si nous pouvons trouver un message d'erreur plus utile pour les versions futures (veuillez voter ou laisser un commentaire sur le rapport de bug):
si vous avez trouvé ce thread en raison du message d'erreur apparaissant en haut de la liste dans certains résultats de recherche et n'utilisez pas Symphony - ce qui s'est produit dans mon cas. Assurez-vous que la méthode d'écriture de votre gestionnaire de session retourne bool - true on success.
le php session_set_save_handler la documentation ne mentionne pas cela. Il est toutefois mentionné dans le SessionHandlerInterface documentation:
la valeur de retour (habituellement vraie sur le succès, FALSE en cas d'échec). Notez que cette valeur est renvoyée en interne à PHP pour traitement.
dans les versions précédentes de PHP, le retour de rien n'a pas entraîné d'erreur. Depuis PHP 7.0, retourner rien n'entraîne l'erreur:Warning: session_write_close(): Failed to write session data (user). Please verify that the current setting of session.save_path is correct (/tmp).
il semble que les versions futures de PHP émettront le message légèrement plus clair. Failed to write session data using user defined save handler.
si vous utilisez Symphony-alors la réponse de Chris Banks fournit une solution plus complète et plus utile à l'original problème.
content de voir que votre problème est résolu - je voulais juste ajouter une autre note pour plus de clarté SI quelqu'un recevant ces erreurs tombe sur ce thread: les erreurs ont évidemment commencé avec un problème dans le pilote framework et/ou sa configuration et c'est pourquoi la mise à jour vers la dernière branche a résolu le problème. Le message d'erreur lui-même s'est produit parce que PHP essayait d'utiliser le pilote de session Redis de Symfony et, en raison de problèmes avec la configuration, est retourné sur le sess.save_path en php.ini. C'est le raison PHP ne pouvait pas écrire dans le répertoire - il essayait d'utiliser l'utilisateur save_handler (Redis) avec le php.ini sess.save_path (fichiers). S'il va retomber aux valeurs par défaut, il devrait utiliser le php.ini sess.save_handler. De toute façon, l'erreur elle-même dans ce cas n'est pas le réel problème.
j'ai eu ce même problème quand je suis passé D'Apache PHP7 à PHP7-FPM. Seule solution pour moi était d'aller à la var répertoire de mon application Symfony et supprimer tous les fichiers, réparer les autorisations sur le var si nécessaire chmod 777. Ensuite, rechargez L'URL de mon application et bon à emporter. Ensuite Symfony recréera tout le cache, les logs, les sessions, etc.