in reply to Re: Cleaning up sessions created by Apache::Session::File when logging out of a CGI application
in thread Cleaning up sessions created by Apache::Session::File when logging out of a CGI application

Thanks, that did the trick. Well, sort of. My session files are getting cleaned up alright and I am probably going to move to a DB_File interface anyway, but when I delete the session, my lock files aren't being cleaned up as well. I thought I could work around this by adding these lines to the top of my script:

my $l = new Apache::Session::Lock::File; $l->clean('./.lockDir', 20);

Just above the lines:

my $scriptName = $query->self_url; $scriptName =~ s/\?.*//;

The problem is, my page where I do the logout modifies the lock, so no matter what it hasn't timed out when we get to the logout processing code, but when I come back into the script later, there are lock files that are hours old and they don't seem to get cleaned up either. I've read the documentation at http://search.cpan.org/author/JBAKER/Apache-Session-1.54/Session/Lock/File.pm and http://search.cpan.org/author/JBAKER/Apache-Session-1.54/Session/File.pm but I guess I still don't understand how the locking mechanism is supposed to work because I'm obviously using it incorrectly. Should I have an external script, maybe a cron job, that cleans up stale lock files? Figuring out which locks belong to sessions that no longer exist in the session directory wouldn't be hard, but I'd really rather understand the proper usage.

Thanks again.

-J.

  • Comment on Re: Re: Cleaning up sessions created by Apache::Session::File when logging out of a CGI application
  • Select or Download Code

Replies are listed 'Best First'.
Re: Re: Re: Cleaning up sessions created by Apache::Session::File when logging out of a CGI application
by cees (Curate) on Feb 10, 2003 at 15:32 UTC

    Well, if you look carefully at the code for the clean method, you will see that it has a bug as well... The culprit is on line 136 of Apache::Session::Lock::File:

    if ((stat($dir.'/'.$file))[8] >= $time) - $now {

    This says: take the last access time of the lock file, subtract the current time and see if it is bigger than the proposed timelimit ($time). Since the current time will always be bigger than the last accees time, this number will always be negative. So unless you provided a negative timelimit to the clean function, the condition for deletion will never be met. Reversing the subtraction should fix the problem.

    if ($now - (stat($dir.'/'.$file))[8] >= $time) {

    Or you could pass a negative time limit to the clean method, but that could break if this bug ever gets fixed and you upgrade.

    Now, again I will try to convince you to scrap the File based sessions and move to at least the DB_File based one.

      Thanks, I'd tried passing a negative value to the time limit as a last act of desperation before posting that, but it didn't seem to help, though I suspect -1 wasn't adequate for the task.

      And don't worry, I'm already convinced to use the DB_File approach. I'd really rather not introduce a dependency on something like MySQL, but DB_File shouldn't be a problem. The only reason I asked about the lock files is that Apache::Session::DB_File also takes a LockDirectory value in the same way ::File does, so I anticipated I'd have the same problem. Next time I'll try it before posting, though.

      -J.