php individual tmp sessions not deleted

Hi,

On my ISPCONFIG server (running on debian 5), I have a little problem with the automatic deletion of tmp files that are in /var/www/clients/clientX/webX/tmp/

In the /etc/php5/apache2/php.ini file, I have :

; This is disabled in the Debian packages, due to the strict permissions
; on /var/lib/php5. Instead of setting this here, see the cronjob at
; /etc/cron.d/php5, which uses the session.gc_maxlifetime setting below.
; php scripts using their own session.save_path should make sure garbage
; collection is enabled by setting session.gc_probability
;session.gc_probability = 0
session.gc_divisor = 100

; After this number of seconds, stored data will be seen as 'garbage' and
; cleaned up by the garbage collection process.
session.gc_maxlifetime = 1440


The cronjob /etc/cron.d/php5 runs every 30 minutes but it delete only tmp files that are in /var/lib/php5


Since all my website have a apache directive :

php_admin_value session.save_path /var/www/clients/client1/web1/tmp

There are many location for tmp files. And so the problem is that all tmp files of each website are not deleted.

Do you know what to do ?
- Should I enabled "session.gc_probability = 1" in my php.ini ?
- Should I remove the session.save_path for each website ?
- Should I write a script to manually delete tmp files ?


Sincerely,
Jerome

 

OK thank you Till,

For information, here is what I am doing now manually :

In each tmp dir :
find -cmin +24 | xargs rm

This command will delete all files that were not changed for 24 minutes.

 

Hello,

i had this Problem twice.
If i open a session and switch from mod_php to fastcgi + suexec the problem start because www-data is the old User and the new user is web??:client??.
The user can't change the file anymore.

Regrads

 

Hello,

I was wondering whether this problem was fixed. I am using ISPConfig version 3.0.5.2 (Debian Wheezy, Apache) and it still seems to be an issue.

Till, perhaps if the deletion script is not in the production, would you be so kind as to provide the script if you managed to write it?

Thank you very much.

 

Yes I confirm this issue was fixed a long time ago.

 

OK, so how is it possible that it's still happening in my installation? Is it possible that I might have misconfigured something? I closely followed the guides on HowtoForge, nothing really special.

Is it possible that these log messages are related to the problem? They appear every 30 minutes in my local mail:
http://pastebin.com/NpPkKSdf

Thank you.

 

@gzx21 You can indeed remove the # on /etc/php5/cli/conf.d/ming.ini and it should make those nasty errors disappear.
@asticot, @till — I know I'm posting three years later, but my ../tmp directories are full of eon-old sessions, and
/usr/lib/php/sessionclean most definitely is not going to delete them, and I don't see anything in
/usr/local/ispconfig/server/lib/classes/cron.d which might be deleting those session files. Where exactly is that 'new' custom script?

 

Ah... I was doing the wrong greps Apparently, it's being run from 200-logfiles.inc.php after the line:

// Cleanup website tmp directories​

Ok so far, but apparently this is not working. It shouldn't be a permissions problem, since, as far as I can see, this script is being run by root. Hm.

 

It works in the sense that it does run without errors; but, as said, my session files seem to start all with phpXXXXXX (where XXX are random alphanumeric characters), so of course this will not catch them.

I can run

Code:

find . -mtime +1 -name 'php*' | grep -v -w .no_delete | xargs rm > /dev/null 2> /dev/null

instead, and of course this will delete them all. Interestingly enough, though, it seems that my current configuration does not write any session files...

 

@till it seems I have the same problem here, the sess_* in the tmp directories are not being deleted. manually running your command (as the specific web user) deletes them. may this be related to using php-fpm?

 

Thanks @till
I would rather not like to switch to the git-stable version but stay with the releases. So that means i have to wait until the fix gets released as I am currently running 3.1.15p2 (could upgrade to p3 but I assume that security fix is not related to the issue with the php session files). Do you know by when this fix should be released in a normal release?

 

all good, I can wait until it is released as it is not an urgent problem, i just noticed it by accident and wanted to make sure it gets resolved.

 

in my case, I can run the script manually, (session files named sess_XXXXX) but ispconfig (3.1.15p3) cron, doesn't clean them up...
hope release 3.1.16 will do it better

 

I had some millions files in website tmp directory. Removed them with attached script. Do not run it unless you understand what it does. Never trust code posted by some randon dude or dudette from the Interwebs.

Code:

#! /bin/bash
# Taleman 2020-04-20
# Bug in Ispconfig or something, old sess* files in website tmp/
# were not removed since 1st October 2019.

cd /var/www/clients/client1
for f in web[0-9]*/tmp/ ; do
   find $f -depth -mtime +7 -type f -delete
done

That code runs pretty fast, much faster than exec rm which I tried first. And I got 20 GB disk space freed.

 

Heaven has sent you @Taleman. I was running out of iNodes and rm wasn't capable to clear the million tmp files inside my folder. So did I understand correctly, that we have to setup a manual cronjob to clear those tmp folders inside the client folders because ISPConfig does not clear those currently?