gc_probability and cache sessions directory growing endlessly

[zefrog]

Hello,

I spent a few hours debugging my system the other day because my disk was full - not because of space but because of inodes. In fact, it was the cache sessions directory that was full of sess_* files.

As it was already stated in pr #1097, on systems like Debian, the default session.gc_probability is defined to 0, and a cron task takes care of the /var/lib/php5 directory, which is the default session.save_path.

But by default, Symfony changes that behavior and puts the sessions in the cache directory of the environment, which is then never garbage collected. If you don't "cache:clear" your environment periodically, you'll be running out of inodes sooner or later (I had some scripts using my webservices, which created sessions over and over again).

I think this issue should be at least documented in session management of the HttpFoundation. But maybe I could also modify the cache:clear task or create a new one, that would only run the garbage collection of sessions. Or do you think it is enough to document that you need to modify the /etc/cron.d/php5 file to change the directory and add more lines for the different environments ?

Regards.

[cordoval]

it is enough to document it and i have opened the issue in docu repo symfony/symfony-docs#3617

please close this issue as it is a duplicate of #1097

[fabpot]

Closing in favor of the doc issue.

[Tobion]

Does it make sense to add a warning to symfonys requirements check when session.gc_probability is 0?

[fabpot]

👍

[zefrog]

Unfortunately, I coudn't find any study saying what portion of production applications are deployed in a debian-like environment. I think a large part is. The 2012 study concentrates on the development environment. The production environment would also be interesting, maybe.

But this is not only a "disk full of inodes" problem. Also a security one, because a session that is never garbage collected can be reused anytime. Correct me if I'm wrong, but I think there is no check of the file mtime when the session is loaded. My sessions are reloaded without a glitch a few days later with the famous "Well this is embarassing" Firefox page.

The session.save_path is redefined. Why not also define a default session.gc_probability ? This can, and should, of course, be configured. And a cron task might be more appropriate in environments where such small optimizations are required.

[fabpot]

@zefrog You can already configure the gc_probability in your Symfony configuration if you want to (see http://symfony.com/doc/current/components/http_foundation/session_configuration.html#configuring-garbage-collection).

[Tobion]

@fabpot I think it makes sense to define a default value for gc_probability in the frameworkbundle config (https://github.com/symfony/symfony/blob/master/src/Symfony/Bundle/FrameworkBundle/DependencyInjection/Configuration.php#L247) since the save_path is also explicitly configured. This way, the problem under Debian should not occur anymore.