Laravel Session files not cleaning from the framework/sessions folder
Asked Answered
S

3

2

I am on a shared host (OVH pro) using Laravel 5.2 on production (PHP 7.0.5).

I am using the file session driver, and everything was working fine on my previous host (with the same app), but since I moved to OVH, the session files keep being created and are never deleted by the PHP garbage collection. I have to manually erase the files (over 5000 files are created per day).

My config/session.php file is set up correctly:

'driver' => 'file',
'lifetime' => 120,
'lottery' => [2, 100],

And my folders storage, storage/framework, storage/framework/sessions are all set with a 0755 permission.

I also override the php.ini by placing those 2 lines at the top of config/session.php

ini_set('session.gc_probability', '5');
ini_set('session.gc_divisor', '100');

It seems to be working fine from what phpinfo() returns: PHP sessions info

I contacted my host, but they told me it must have to do with my Laravel app, and they can't help.

Edit: My sessions work fine, I mean that there's only one file created per visitor. The problem is only the fact that the session files are not getting cleaned up, even with a 777 permission.


Even when I put the Laravel session lottery to 100/100, the files are still not getting deleted:

    /*
    |--------------------------------------------------------------------------
    | Session Sweeping Lottery
    |--------------------------------------------------------------------------
    |
    | Some session drivers must manually sweep their storage location to get
    | rid of old sessions from storage. Here are the chances that it will
    | happen on a given request. By default, the odds are 2 out of 100.
    |
    */

    'lottery' => [100, 100],

EDIT: OVH hosting specifics: I use multisites on OVH, and the folders containing each site are placed at the route of my OVH host, and not in the default www folder.

I did that for security reasons, because the www folder is publicly available through mynickname.cluster005.ovh.net and I dont want any of my sites to be publicly available from

mynickname.cluster005.ovh.net/site1

mynickname.cluster005.ovh.net/site2...

(www\site1, www\site2...).

So I was thinking that maybe only the files located inside www folder are writable, and maybe not the one outside (at the root)? That would explain while my files are not being deleted. I'll make a test tonight to see if the files are being deleted when placed in www\site1\storage\sessions.

Sheepshanks answered 5/5, 2016 at 23:58 Comment(8)
try to add this in logout method Session::flush();Heartsick
That's smart, but most people just leave websites without logout, I would just save a dozen of file...Sheepshanks
Cant you just Scheduling that then? Not the best solution i knowHeartsick
Scheduling a cron job was my plan too, but this is my second big problem >< #37062270Sheepshanks
ah :s i never used Scheduling so i can't help , i hope u fix thisHeartsick
Have you: 1. tried to change lifetime 2. checked the last modification date of the session files I've tried locally and have no problem: files are deleted. I've played with lifetime and lottery parameters and have encountered no problem. Did not try on OVH, since I already have something installed there. But I can take a moment tomorrow to configure a new site to check with the same configuration as yours. It really seems to be a permissions issue, but you already have tried many configurations...Smalls
I have changed 'expire_on_close' from false to true, and it now seems that number of session files are decreasing very slowly (~2 files less per hour on a total of 2000), but at least, it's decreasing so files are indeed deleted which means it's not a permission issue afterall. I'll try to play more with the session options until I find something suitable. But as of now, it seems that the problem is resolved, eventhough I am still not sure of what caused it.Sheepshanks
That's very strange. I also just realized you use PHP 7, while I'm still using PHP 5.6, even on my OVH shared hosting. Anyway, now that you can run a scheluded task, you might write a small command to delete old session files if you wish (having a look at Illuminate\Session\FileSessionHandler::gc() method). It does not explain why this happen, but it helps cleaning the sessions files while letting you time to find out what causes files not to be deleted by GC.Smalls
L
0

There some step that you can find what's problem is first

  1. Make sure session ID is fixed in every page (echo session id)

if session id was changed every page , you need to check your session config domain setting is correct.

if session id didn't change maybe you need change storage folder premision to 777.

I hope that can help you.

Lympho answered 6/5, 2016 at 1:47 Comment(1)
My sessions work fine, I mean that there's only one file created per visitor. The problem is only the fact that the session files are not getting cleaned up, even with a 777 permission.Sheepshanks
F
0

If you are using haproxy, consider this answer:

Session files may be created by the haproxy's http health checks.

  1. Check your web access logs to fixed interval access.

111.11.111.1 - - [28/Jul/2016:10:40:30 -0400] 200 "GET / HTTP/1.0" 4 "-" "-" "-"

111.11.111.1 - - [28/Jul/2016:10:40:32 -0400] 200 "GET / HTTP/1.0" 4 "-" "-" "-"

111.11.111.1 - - [28/Jul/2016:10:40:34 -0400] 200 "GET / HTTP/1.0" 4 "-" "-" "-"

  1. Update option httpchk GET / to point to some routes that you could set the session driver to be array on your haproxy.cfg.

  2. add the Config::set('session.driver', 'array'); line to disable creation of session files.


Reference:

Flieger answered 28/7, 2016 at 14:52 Comment(0)
B
0

Go to config/session and set 'lifetime' => 120, or a number not too large, this is how long a session lasts in minutes

Barkley answered 8/1, 2020 at 12:31 Comment(0)

© 2022 - 2024 — McMap. All rights reserved.