Я скомпилировал 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 не удается написать сеансы?
PHP7 более строг с обработкой сеанса для пользовательских обработчиков сеансов. Собственный обработчик сеансов Symfony для его метода записи по какой-то причине возвращает false. Раньше это не вызывало ошибки, но теперь это происходит.
Поскольку у нас нет большой информации о том, какой пользовательский обработчик сеанса вы используете, я бы предложил установить другой пользовательский обработчик сеанса, если это возможно, поскольку большинство из них возвращают true.
Вот разные обработчики сеансов Symfony, большинство из них явно возвращают true, за исключением Memcache и WriteCheckSessionHandler:
РЕДАКТИРОВАТЬ:
Поскольку вы упоминаете обработчик сеанса Snc Redis Bundle, уверены ли вы, что используете самую последнюю версию? Год назад он был изменен, чтобы всегда возвращать true при записи:
https://github.com/snc/SncRedisBundle/blob/master/Session/Storage/Handler/RedisSessionHandler.php
ОБНОВИТЬ
Представлена ошибка для PHP, чтобы узнать, можем ли мы найти более полезное сообщение об ошибке для будущих версий (проголосовать или оставить комментарий к отчету об ошибке):
Если вы нашли этот поток из-за сообщения об ошибке, появляющегося в верхней части списка в некоторых результатах поиска, и не используете 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) 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 дает более полное и полезное решение исходной проблемы.
Рад видеть, что ваша проблема решена – просто хотелось добавить еще одно примечание для ясности, если кто-то, кто получает эти ошибки, наткнулся на этот поток: ошибки, очевидно, начались с проблемы в драйвере фреймворка и / или его конфигурации, и именно поэтому обновление до последних отрасль разрешила проблему. Само сообщение об ошибке произошло из-за того, что PHP пытался использовать драйвер сеанса Symfony Redis и, из-за проблем с конфигурацией, вернулся к sess.save_path в php.ini. Именно по этой причине PHP не мог писать в каталог – он пытался использовать пользователя save_handler (Redis) с php.ini sess.save_path (файлы). Если он будет возвращаться к значениям по умолчанию, он должен также использовать настройку php.ini sess.save_handler. В любом случае сама ошибка в этом случае не указывает на актуальную проблему.
У меня была такая же проблема, когда я перешел с Apache PHP7 на PHP7-FPM. Исправить только для меня было перейти в каталог var моего приложения Symfony и удалить все файлы там, исправить разрешения для var, если необходимо chmod 777. После этого перезагрузите URL-адрес моего приложения и хорошо пойдите. После этого Symfony будет воссоздавать все кеши, журналы, сеансы и т. Д.