1

I sometimes need to use both $_SESSION and $_COOKIE as well as setcookie() inside some php script. They both work fine. But ...

The problem:

Every now and then the php garbage collector fires and throws an error on pages that run scripts with both $_SESSION and $_COOKIE usage. The error being:

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

By the way
I use these php.ini settings:

session.gc_probability = 1
session.gc_divisor     = 100
session.gc_maxlifetime = 1800

Considerations
There is much discussion on the net about this phenomena, but the only relevant idea comes from the php bug report forum. Scroll to the very end of the page and find:

The cause of it was that I used sessions AND cookies in one script. I commented all the 'setcookie' lines and all other cookie functions in my script and ... the problem vanished!

The hack
Well, splitting $_SESSION and $_COOKIE use to two scripts was not an option as of now, but I manualy disable the garbage collector for each script concerned via @gc_disable(). But a hack, is a hack, is a hack, is a hack ;)

Suggestions?
Use the php.ini setting session.gc_probability=0 to kill off the garbage collection altogether as discussed in this answer or here and here
Result: Does not prevent the gc from running on my site, oddly enough. Why? I don't know.

Solution:

After setting a session.save_path the garbage collection stopped throwing errors. I'm also using the default "session.gc_" directives now. PHP-version 5.4.9

session.save_path = /website/sessions
Community
  • 1
  • 1
maxpower9000
  • 223
  • 2
  • 8
  • 1
    Is this on win32? If so, the "permission denied" might be because the session file is still open from another script (possibly the same script) from another connection thread in the same browser. This happens all the time with old-style "upload progress" scripts. – David-SkyMesh Mar 27 '12 at 08:29
  • 1
    Does the webserver have execute rights on `/var/lib/php5`? I think he needs this to list this dir's files and without it he cannot garbage collect. You should be able to have it happen more often when you set `session.gc_divisor = 1` This way the garbage collection probability will be `100%`. You could just set `session.save_path` to some directory which is writeable to the webserver, maybe something on your document root. – Basti Mar 27 '12 at 08:55
  • @David-SkyMesh Thanks! Well, the user side is Win7 x64, but the site runs on Unix. And there is no "upload" happening. – maxpower9000 Mar 27 '12 at 08:56
  • @Basti Okay. I actually tried that tack before, but found the directive `session.save_path` to open up a whole new box of problems on my server. I am still talking with the server guys about the why. Hopefully I can try your suggestion in the near future. – maxpower9000 Mar 27 '12 at 09:00
  • I tryed this on my Mac and PHP was not able to use the directory for sessions without execute rights, so that should not be the problem. :-( – Basti Mar 27 '12 at 09:03
  • 1
    Someone has the same problem: http://stackoverflow.com/questions/2904862/issues-with-php-5-3-and-sessions-folder and external http://vvv.tobiassjosten.net/php/php-session-garbage-collection – Basti Mar 27 '12 at 09:05
  • Are you sure this is an error? It should be a notice (hence suppressable). Which version of PHP ? (see bug #2070). As David-SkyMesh says, it's likely a file locking issue (MSWindows is much more heavy handed than Unix - but the latter will still lock files in some configurations). Also, check that all the session files are owned by the webserver uid. – symcbean Mar 27 '12 at 09:08
  • @symcbean It actually throws a **PHP WARNING** not an error or notice. I will look into your comment further soon. Thanks! – maxpower9000 Mar 27 '12 at 11:14
  • @Basti The _solution_ `session.gc_probability=0` in the php.ini as suggested [here](http://stackoverflow.com/questions/2904862/issues-with-php-5-3-and-sessions-folder) does not do it for me. I don't know why, but the gc keeps running eventually. I actually read and tried that particular suggestion already :( – maxpower9000 Mar 27 '12 at 12:19
  • Thanks for all contributions so far! **Please consider**: the problem **only** occurs on pages (or individual scripts) that use both the $_SESSION and $_COOKIE superglobals, **not** on any other page (and there are many). So the problem likely lies not with the _server permissions_ or the _session save path_. That's what freaks me out ;) Please keep posting suggestions! – maxpower9000 Mar 27 '12 at 12:29

0 Answers0