PHP7 + Symfony 2.8, Failed to write session data

Question

i compiled php7 on my own (974f6c2a705). if i run php7 + php-fpm + nginx using symfony i get this error:

(using the snc redis bundle for sessions:)

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

(using the native session support:)

 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)

the problem seems to be symfony related, because php has read / write access to the folder.

if i run nothing but this code, it works:

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

any suggestions or ideas why symfony fails to write the sessions?

Answer 1

PHP7 is more strict with session handling for custom session handlers. Symfony's custom session handler for its write method is, for whatever reason, returning false. Previously this did not trigger an error but now it does.

Since we do not have a lot of information on which custom session handler you are using, I would suggest setting a different custom session handler if possible since most of them appear to return true.

Here are the different session handlers Symfony, most of them appear to explicitly return true except for the Memcache ones and WriteCheckSessionHandler:

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

EDIT:

Since you mention the Snc Redis Bundle session handler, are you sure you are using the most up-to-date version? A year ago it was modified to always return true on write:

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

UPDATE

Submitted a bug to PHP to see if we can figure out a more useful error message for future versions (please vote or leave a comment on the bug report):

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

Answer 2

If you found this thread because of the error message appearing top of the list in some search results and are not using Symphony - which happened in my case. Make sure the write method of your session handler returns bool - true on success.

The php session_set_save_handler documentation doesn't mention this. It is however mentioned in the SessionHandlerInterface documentation:

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

In earlier versions of PHP, returning nothing did not result in an error. Since PHP 7.0, returning nothing results in the error: Warning: session_write_close(): Failed to write session data (user). Please verify that the current setting of session.save_path is correct (/tmp).

It does look as though future versions of PHP will issue the slightly clearer message. Failed to write session data using user defined save handler.

If you are using Symphony - then the answer from Chris Banks provides a fuller and more useful solution to the original problem.

Answer 3

Glad to see your issue is resolved - just wanted to add another note for clarity if somebody receiving these errors stumbles upon this thread: the errors obviously started with an issue in the framework driver and/or its config and this is why updating to the latest branch resolved the issue. The error message itself occurred because PHP was attempting to use the Symfony Redis session driver and, due to issues with the config, reverted to the sess.save_path in php.ini. This is the reason PHP could not write to the directory - it was attempting to use the user save_handler (Redis) with the php.ini sess.save_path (files). If it is going to fall back to defaults, it should be using the php.ini sess.save_handler setting as well. Either way, the error itself in this case does not point to the actual issue.

Answer 4

I had this same issue when I moved from Apache PHP7 to PHP7-FPM. Only fix for me was to go to the var directory of my Symfony app and remove all the files there, fix the permissions on the var if needed chmod 777. Afterwards reload the URL of my app and good to go. Afterwards Symfony will re-create all the cache, logs, sessions, etc.