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 не удается записать сеансы?

Ответы

Ответ 1

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

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

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

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

EDIT:

Поскольку вы упоминаете обработчик сеанса Snc Redis Bundle, уверены ли вы, что используете самую последнюю версию? Год назад он был изменен, чтобы всегда возвращать true при записи:

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

UPDATE

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

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

Ответ 2

Если вы нашли этот поток из-за сообщения об ошибке, появляющегося в верхней части списка в некоторых результатах поиска, и не используете Symphony - это произошло в моем случае. Убедитесь, что метод записи обработчика сеанса возвращает 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 - тогда ответ от Chris Banks дает более полное и полезное решение исходной проблемы.

Ответ 3

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

Ответ 4

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