You are viewing a plain text version of this content. The canonical link for it is here.
Posted to mod_python-dev@quetz.apache.org by dharana <dh...@dharana.net> on 2005/10/09 12:04:52 UTC
FileSession automatic cleaning seems to be on vacation
I think there is a problem with the autocleaning function in
FileSession. I'm using Mod_Python 3.2.2b in a live server and I today I
noticed this:
/tmp/mp_sess # df -h /tmp
Filesystem Size Used Avail Use% Mounted on
/dev/sda7 989M 544M 395M 58% /tmp
/tmp/mp_sess # df -i /tmp
Filesystem Inodes IUsed IFree IUse% Mounted on
/dev/sda7 128768 128768 0 100% /tmp
/tmp/mp_sess # ll /tmp/
total 24
drwxrwxrwt 2 root root 4096 Oct 6 11:43 .ICE-unix/
drwx------ 2 root root 16384 Jun 14 22:30 lost+found/
drwxr-x--- 258 httpd sys 4096 Oct 6 06:04 mp_sess/
And, after executing this:
/tmp/mp_sess # find ./ -mmin +1440 -exec rm {} \;
I get this:
/tmp/mp_sess # df -i /tmp
Filesystem Inodes IUsed IFree IUse% Mounted on
/dev/sda7 128768 23857 104911 19% /tmp
So I think FileSession isn't doing its work. Any ideas?
--
dharana
Re: FileSession automatic cleaning seems to be on vacation
Posted by Jim Gallacher <jg...@sympatico.ca>.
dharana wrote:
> Hello Jim,
>
> sorry for the lag. Here is the .mp_sess.lck info:
>
> /tmp/mp_sess # ll /tmp/mp_sess/.mp_sess.lck
> -rw-r----- 1 httpd sys 0 Oct 12 01:56
> /tmp/mp_sess/.mp_sess.lck
>
> I didn' touched anything in /tmp after my last email but I have had to
> add a cronjob with the find line.
>
> If I can do anything more to help debug this tell me.
>
A .mp_sess.lck file more than 2 or 3 seconds old indicates a stale lock
file. This file should be deleted at the end of each cleanup but the
fact that it's there means something went wrong (or a cleanup is running
at the precise moment you ran the ls command). You can safely delete
this file to end the cleanup "vacation".
Take a look in the apache error log. A successful cleanup will log
messages similar to the following:
[Wed Oct 12 13:13:58 2005] [notice] [client 192.168.1.2] FileSession:
registered filesession cleanup., referer:
http://www.example.com/mod_python/session/
[Wed Oct 12 13:13:58 2005] [notice] [client 192.168.1.2] FileSession
cleanup: (fast=True, verify=True) ..., referer:
http://www.example.com/mod_python/session/
[Wed Oct 12 13:13:58 2005] [notice] [client 192.168.1.2] FileSession
cleanup: deleted 3 of 1501 in 0.3012 seconds, referer:
http://www.example.com/mod_python
If a request attempts to run the cleanup while another request is
already running a cleanup you should see something like this:
[Wed Oct 12 13:10:41 2005] [notice] [client 192.168.1.2] FileSession:
registered filesession cleanup.
[Wed Oct 12 13:10:41 2005] [notice] [client 192.168.1.2] FileSession
cleanup: (fast=True, verify=True) ...
[Wed Oct 12 13:10:41 2005] [notice] [client 192.168.1.2] FileSession
cleanup: another process is already running.
I'm assuming you are only seeing the second group of messages repeated.
Delete /tmp/mp_sess/.mp_sess.lck and see what happens. You can force the
cleanup to run by calling the cleanup() method of your session object,
ie. sess.cleanup().
Regards,
Jim
> Jim Gallacher wrote:
>
>> dharana wrote:
>>
>>> I think there is a problem with the autocleaning function in
>>> FileSession. I'm using Mod_Python 3.2.2b in a live server and I today
>>> I noticed this:
>>>
>>>
>>> /tmp/mp_sess # df -h /tmp
>>> Filesystem Size Used Avail Use% Mounted on
>>> /dev/sda7 989M 544M 395M 58% /tmp
>>>
>>>
>>> /tmp/mp_sess # df -i /tmp
>>> Filesystem Inodes IUsed IFree IUse% Mounted on
>>> /dev/sda7 128768 128768 0 100% /tmp
>>>
>>>
>>> /tmp/mp_sess # ll /tmp/
>>> total 24
>>> drwxrwxrwt 2 root root 4096 Oct 6 11:43 .ICE-unix/
>>> drwx------ 2 root root 16384 Jun 14 22:30 lost+found/
>>> drwxr-x--- 258 httpd sys 4096 Oct 6 06:04 mp_sess/
>>>
>>>
>>> And, after executing this:
>>>
>>> /tmp/mp_sess # find ./ -mmin +1440 -exec rm {} \;
>>>
>>>
>>>
>>> I get this:
>>>
>>> /tmp/mp_sess # df -i /tmp
>>> Filesystem Inodes IUsed IFree IUse% Mounted on
>>> /dev/sda7 128768 23857 104911 19% /tmp
>>>
>>> So I think FileSession isn't doing its work. Any ideas?
>>>
>>
>> Could you check:
>> ls -l /tmp/mp_sess/.mp_sess.lck
>>
>> It should only exist when a cleanup is running.
>>
>> .mp_sess.lck is a lock file to ensure only one cleanup process/thread
>> is running at one time. If something went wrong during a cleanup
>> (segfault?) then this lock file might not have been deleted. If an
>> stale lock file exists any subsequent cleanup will exit without doing
>> anything. If it exists delete it and see if the cleanup will run to
>> completion.
>>
>> If this lock file looks like it might create problems I can add a
>> check to see if it's stale.
>>
>> Regards,
>> Jim
>>
>>
>>
>>
>
Re: FileSession automatic cleaning seems to be on vacation
Posted by dharana <dh...@dharana.net>.
Hello Jim,
sorry for the lag. Here is the .mp_sess.lck info:
/tmp/mp_sess # ll /tmp/mp_sess/.mp_sess.lck
-rw-r----- 1 httpd sys 0 Oct 12 01:56
/tmp/mp_sess/.mp_sess.lck
I didn' touched anything in /tmp after my last email but I have had to
add a cronjob with the find line.
If I can do anything more to help debug this tell me.
Jim Gallacher wrote:
> dharana wrote:
>> I think there is a problem with the autocleaning function in
>> FileSession. I'm using Mod_Python 3.2.2b in a live server and I today
>> I noticed this:
>>
>>
>> /tmp/mp_sess # df -h /tmp
>> Filesystem Size Used Avail Use% Mounted on
>> /dev/sda7 989M 544M 395M 58% /tmp
>>
>>
>> /tmp/mp_sess # df -i /tmp
>> Filesystem Inodes IUsed IFree IUse% Mounted on
>> /dev/sda7 128768 128768 0 100% /tmp
>>
>>
>> /tmp/mp_sess # ll /tmp/
>> total 24
>> drwxrwxrwt 2 root root 4096 Oct 6 11:43 .ICE-unix/
>> drwx------ 2 root root 16384 Jun 14 22:30 lost+found/
>> drwxr-x--- 258 httpd sys 4096 Oct 6 06:04 mp_sess/
>>
>>
>> And, after executing this:
>>
>> /tmp/mp_sess # find ./ -mmin +1440 -exec rm {} \;
>>
>>
>>
>> I get this:
>>
>> /tmp/mp_sess # df -i /tmp
>> Filesystem Inodes IUsed IFree IUse% Mounted on
>> /dev/sda7 128768 23857 104911 19% /tmp
>>
>> So I think FileSession isn't doing its work. Any ideas?
>>
>
> Could you check:
> ls -l /tmp/mp_sess/.mp_sess.lck
>
> It should only exist when a cleanup is running.
>
> .mp_sess.lck is a lock file to ensure only one cleanup process/thread is
> running at one time. If something went wrong during a cleanup
> (segfault?) then this lock file might not have been deleted. If an stale
> lock file exists any subsequent cleanup will exit without doing
> anything. If it exists delete it and see if the cleanup will run to
> completion.
>
> If this lock file looks like it might create problems I can add a check
> to see if it's stale.
>
> Regards,
> Jim
>
>
>
>
--
dharana
Re: FileSession automatic cleaning seems to be on vacation
Posted by Jim Gallacher <jg...@sympatico.ca>.
dharana wrote:
> I think there is a problem with the autocleaning function in
> FileSession. I'm using Mod_Python 3.2.2b in a live server and I today I
> noticed this:
>
>
> /tmp/mp_sess # df -h /tmp
> Filesystem Size Used Avail Use% Mounted on
> /dev/sda7 989M 544M 395M 58% /tmp
>
>
> /tmp/mp_sess # df -i /tmp
> Filesystem Inodes IUsed IFree IUse% Mounted on
> /dev/sda7 128768 128768 0 100% /tmp
>
>
> /tmp/mp_sess # ll /tmp/
> total 24
> drwxrwxrwt 2 root root 4096 Oct 6 11:43 .ICE-unix/
> drwx------ 2 root root 16384 Jun 14 22:30 lost+found/
> drwxr-x--- 258 httpd sys 4096 Oct 6 06:04 mp_sess/
>
>
> And, after executing this:
>
> /tmp/mp_sess # find ./ -mmin +1440 -exec rm {} \;
>
>
>
> I get this:
>
> /tmp/mp_sess # df -i /tmp
> Filesystem Inodes IUsed IFree IUse% Mounted on
> /dev/sda7 128768 23857 104911 19% /tmp
>
> So I think FileSession isn't doing its work. Any ideas?
>
Could you check:
ls -l /tmp/mp_sess/.mp_sess.lck
It should only exist when a cleanup is running.
.mp_sess.lck is a lock file to ensure only one cleanup process/thread is
running at one time. If something went wrong during a cleanup
(segfault?) then this lock file might not have been deleted. If an stale
lock file exists any subsequent cleanup will exit without doing
anything. If it exists delete it and see if the cleanup will run to
completion.
If this lock file looks like it might create problems I can add a check
to see if it's stale.
Regards,
Jim