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
This is a problem in php. If a custom session tmp dir is defined, php will not care about removing sessions files anymore. The best way to solve this is to write a custom script. We will add such a script in ispconfig too to fix this php problem.
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.
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 directoriesOk 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.
Does the command work when you run it manually? Code: cd /var/www/clients/client0/web1/tmp; find . -mtime +1 -name 'sess_*' | grep -v -w .no_delete | xargs rm > /dev/null 2> /dev/null
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?
No, that's a different issue in ISPConfig which has been solved already. Update ISPConfig to git-stable using ispconfig_update.sh command.
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?
The easier way is to update ispconfig to git-stable branch using ispconfig_update.sh, where the issue has been fixed.