PHP7 + Symfony 2.8, не удалось записать данные сеанса

я скомпилировал php7 самостоятельно (974f6c2a705). если я запускаю php7 + php-fpm + nginx с помощью symfony, я получаю эту ошибку:

(использование пакета snc redis для сеансов:)

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

(используя собственную поддержку сеанса:)

 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)

проблема, похоже, связана с symfony, потому что php имеет доступ для чтения / записи в папку.

Если я не запускаю ничего, кроме этого кода, он работает:

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

любые предложения или идеи, почему symfony не удается написать сеансы?

17
php php-7 symfony

4 ответов

PHP7 более строг с обработкой сеанса для пользовательских обработчиков сеанса. Пользовательский обработчик сеанса Symfony для его метода write по какой-либо причине возвращает false. Раньше это не вызывало ошибки, но теперь это происходит.

поскольку у нас нет много информации о том, какой пользовательский обработчик сеанса вы используете, я бы предложил установить другой пользовательский обработчик сеанса, если это возможно, так как большинство из них, похоже, возвращают true.

вот разные обработчики сеансов Symfony, большинство из которых явно возвращают true за исключением Memcache и WriteCheckSessionHandler:

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

EDIT:

поскольку вы упомянули обработчик сеанса SNC Redis Bundle, вы уверены, что используете самую последнюю версию? Год назад он был изменен на always верните true на write:

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

обновление

отправил ошибку на PHP, чтобы узнать, можем ли мы выяснить более полезное сообщение об ошибке для будущих версий (пожалуйста, проголосуйте или оставьте комментарий к отчету об ошибке):

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

10

Если вы нашли этот поток из - за сообщения об ошибке, появляющегося в верхней части списка в некоторых результатах поиска, и не используете Symphony-что произошло в моем случае. Убедитесь, что метод write вашего обработчика сеанса возвращает bool - true on success.

php session_set_save_handler в документации об этом не упоминается. Однако он упоминается в SessionHandlerInterface документы:

возвращаемое значение (обычно TRUE при успехе, False в случае возникновения ошибки). Примечание это значение возвращается внутри PHP для обработки.

в более ранних версиях PHP возврат ничего не привел к ошибке. Начиная с PHP 7.0, возврат ничего не приводит к ошибке:Warning: session_write_close(): Failed to write session data (user). Please verify that the current setting of session.save_path is correct (/tmp).

похоже, что будущие версии PHP будут выдавать немного более четкое сообщение. Failed to write session data using user defined save handler.

Если вы используете Symphony-тогда ответ от Криса Бэнкса предоставляет более полное и полезное решение для оригинала проблема.

4

рад видеть, что ваша проблема решена - просто хотел добавить еще одну заметку Для ясности, если кто-то, получающий эти ошибки, натыкается на этот поток: ошибки, очевидно, начались с проблемы в драйвере framework и/или его конфигурации, и именно поэтому обновление до последней ветви решило проблему. Само сообщение об ошибке произошло, потому что PHP пытался использовать драйвер сеанса Symfony Redis и из-за проблем с конфигурацией вернулся к sess.save_path в php.ini. Это причина, по которой PHP не мог писать в каталог - он пытался использовать пользователя save_handler (Redis) с php.ini sess.save_path (файлов). Если он собирается вернуться к умолчанию, он должен использовать php.ini sess.установка save_handler, а также. В любом случае, сама ошибка в этом случае не указывает на фактический выпуск.

2

У меня была такая же проблема, когда я перешел с Apache PHP7 на PHP7-FPM. Только исправить для меня было перейти в каталог var моего приложения Symfony и удалить все файлы там, исправить разрешения на var, если это необходимо chmod 777. После этого перезагрузите URL-адрес моего приложения и хорошо идти. После этого Symfony повторно создаст весь кэш, журналы, сеансы и т. д.

0