Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

session.gc_probability being over written by the kernel #21641

Closed
MicWit opened this issue Feb 17, 2017 · 8 comments
Closed

session.gc_probability being over written by the kernel #21641

MicWit opened this issue Feb 17, 2017 · 8 comments

Comments

@MicWit
Copy link

MicWit commented Feb 17, 2017

Q A
Bug report? yes
Feature request? no
BC Break report? no
RFC? no
Symfony version 3.2.4

I am trying to implement sessions on the database using https://github.com/shapecode/doctrine-session-handler-bundle. One of the things I need to test is that sessions are being cleaned up using the gc method. So I changed session.gc_probability in php.ini from the red hat default of 1 (out of 1000, most are out of 100) to 1000, to make it try and clear every time. When it wasn't I started echoing the variable in app_dev.php to see what was going on, and found it was being reset somewhere in
$response = $kernel->handle($request);
In order to test this, you can just change the lines (in a new install of Symfony) from:

$request = Request::createFromGlobals();
$response = $kernel->handle($request);
$response->send();

to:

$request = Request::createFromGlobals();
echo ini_get('session.gc_probability');
$response = $kernel->handle($request);
echo ini_get('session.gc_probability');
$response->send();

and look at the results. You should end up with 10001, the 1000 being the first time it is echoed (or whatever value you set this to in php.ini) and then the second time it has been changed to 1.

According to the Symfony documentation at http://symfony.com/doc/current/components/http_foundation/session_configuration.html#configuring-garbage-collection, it uses the values in php.ini to set the chances of gc happening.

This would be ok if it worked properly, as in dev we could set it to 100% of the time to test expiry of sessions (for example from the database). As far as I am aware, it should never change this variable from the value it is set to in php.ini.

@ogizanagi
Copy link
Member

The default value for the framework.session.gc_probability has been set to 1 on purpose in #10366 to workaround some issues with debian distributions changing the PHP configuration by setting it to 0. I don't know if this is still true and if the default value can possibly be removed.
But you could solve your issue by setting explicitly:

# config.yml
framework:
    session:
        gc_probability: null

to keep using the value defined in you php.ini file.

@mvrhov
Copy link

mvrhov commented Feb 18, 2017

Debian's default is still 0. Debian has a script that clears the sessions periodically. But unfortunately this one only clears in the default directory. If you change it you either have to change the script or set the flag to 1

@MicWit
Copy link
Author

MicWit commented Feb 18, 2017

Why not look at the value in php.ini and if it is 0 set it as 1 else use the value? Either way, this should be reflected in the documentation.

@mvrhov
Copy link

mvrhov commented Feb 19, 2017

None of the components looks at how something is set. You have to set it explicitly or leave alone which means that default value is used.

@MicWit
Copy link
Author

MicWit commented Feb 19, 2017

from @ogizanagi:

But you could solve your issue by setting explicitly:

config.yml

framework:
session:
gc_probability: null
to keep using the value defined in you php.ini file.

This is the way to go for sure, but this REALLY needs to be updated in the documentation at http://symfony.com/doc/current/components/http_foundation/session_configuration.html#configuring-garbage-collection so that in future users will be able to understand how gc works now.

@ogizanagi
Copy link
Member

ogizanagi commented Feb 19, 2017

@MicWit : I agree. It's documented in the FrameworkBundle config reference page, though (the default value). But maybe you could try to submit a PR to the symfony/symfony-doc repository to enhance the page you mentioned as well as explaining the null behavior? :)

@MicWit
Copy link
Author

MicWit commented Feb 19, 2017

Done, though I'm not 100% on the documentation code, the pull request is at symfony/symfony-docs#7514 if you want a look? I also couldn't work out links in it (I looked at some other source code but there was no source for the link etc)

@javiereguiluz
Copy link
Member

Closing it in favor the doc PR symfony/symfony-docs#7514

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

6 participants