TIP: Use Markdown or, <pre> for multi line code blocks / <code> for inline code.
These forums are read-only and for archival purposes only!
Please join our new forums at discourse.kohanaframework.org
Garbage collector error with sessions on Debian
  • Hi all.

    I'm experiencing an error with the garbage collection when using session library. It happens randomly and not that often but it happens :)

    The error is:

    session_start() [function.session-start]: ps_files_cleanup_dir: opendir(/var/lib/php5) failed: Permission denied (13)

    I google a while to solve this problem and I found this:

    Frustratingly, if you do receive this error, you'll only get it once every hundred page loads on average. Which points to the cause of the problem: automatic session garbage collection. In Debian and Ubuntu, /var/lib/php5, where the session data is stored, has permissions of drwx-wx-wt and should only be cleaned by a cron script.

    Solutions found among others:
    - Prefixing the session call with '@'
    - change the group to www-data and grant group read permissions with "chmod g+r" (slightly more secure than the one below)
    - change the directory permissions to be world-readable
    - disable garbage collection in the session config file

    Any thoughts on this? Did someone got the same error?
  • This should only happen if you are using the native driver and your session files are stored in the default location var/lib/php5 Debian/Ubuntu has default setting of gc_probability = 0 in PHP.ini Kohana is setting gc_probability = [session.config.gc_probability] and so you get an error when a write attempt is made to var/lib/php5 which is root only.

    To prevent this error, you should switch off garbage collection in session config and let debian/ubuntu cron job clean up the session files.

    /**
    * Percentage probability that the gc (garbage collection) routine is started.
    */
    $config['gc_probability'] = 0;
    

    This does not apply if custom save handlers are defined php manual Kohana's session (for NON native) defines it's own set_save_handler, so you must configure a gc_probability > 0 if you want old sessions cleaned up. (If you are not using the native driver.)

    Debian/Ubuntu cron job does not clean up old sessions if you have specified your own file_save_path, so you would need to add that to PHP.ini. and explicitly enable gc_probability = (>0)

  • Report a bug to Ubuntu. They are breaking PHP functionality.

  • Posted By: ShadowhandReport a bug to Ubuntu. They are breaking PHP functionality.
    Yeah really!

    I use Ubuntu however as a desktop, localhost and server and I've never seen this error. I'll try to do some testing for you.
  • Hi. I'm new user of Kohana framework and I must say that it's great.

    But I was totally frustrated when I got this "... Permission denied .." session error on my Debian server. So I suggest to add a notice into default session config file:

    maybe something like:


    /**
    * Percentage probability that the gc (garbage collection) routine is started.
    *
    * If you are using Debian/Ubuntu and default storage directory /var/lib/php5 then
    * set here gc_probability to 0 and let Debian/Ubuntu cron job clean the directory.
    */
    $config['gc_probability'] = 0;


    Thanks.
  • Just encountered this too, glad to find the fix so easily.
  • Posted By: Kudos

    Just encountered this too, glad to find the fix so easily.



    I got this message today, the second day since I've moved my web application to Debian server :). I never got it before in 2 years of hosting this app. That's one of the reasons why I love Kohana so much, community is great!
  • I got the same message, now im a novice to ubuntu server so any details of getting this fixed would be greatly appreciated. I have ubuntu lucid latest, the questions i have is 1.) What chmod setting should i set the dir to for /php5, 775? 755? 2.) Where is the file session.config located in ubuntu? I looked at the php.ini file but it does not indicate the line gc_probability = (>0), i know that i can edit the php.ini but i hear horror sometimes follow close to ones edits.

  • If you are using the native driver and your session files are stored in the default location var/lib/php5 you can recreate this error on every request by placing the following two lines in system/config/session.php:

    ini_set('session.gc_probability',1000);
    ini_set('session.gc_divisor',1000);
    

    If you want to recreate the error 1 out of 2 times on average use the following

    ini_set('session.gc_probability',500);
    ini_set('session.gc_divisor',1000);
    
  • We spotted this problem on one of our servers. Basically the solution is to make sure the files are only deleted if nothing is using them.

    We edited /etc/cron.d/php5

    The command part of the crontab was this: SEE NEXT POST

    [ -x /usr/lib/php5/maxlifetime ] && [ -d /var/lib/php5 ] && find /var/lib/php5/ -type f -cmin +$(/usr/lib/php5/maxlifetime) -delete
    

    We changed it to: SEE NEXT POST

    [ -x /usr/lib/php5/maxlifetime ] && [ -d /var/lib/php5 ] && find /var/lib/php5/ -type f -cmin +$(/usr/lib/php5/maxlifetime) -exec sh -c 'C=`fuser $0 2> /dev/null | wc -w`; [ "$C" -eq 0 ] && rm $0' {} \;
    

    Instead of just deleting the file, we use fuser to see if there any processes with the file open, and only delete if there aren't.

  • Woot, this bug should be fixed in upcoming releases.

    The previous solution I posted was not as efficient or secure as it could have been. See the bug report thread, or newer releases, for a newer version.

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

In this Discussion