I've seen this problem on a busy server. Symptoms:
* old files in /var/lib/php/session aren't removed despite this script
* high latency on file operations due to the growing 'session' directory size
* hourly high load average due to many fuser processes
The reason: find 'execdir' appears to have a bug where it doesn't release file handles. It quickly runs into the default maximum of 1024 and the find process quits. So it deletes
some files, but not all. In the case I saw, it was deleting them more slowly than they were accumulating.
The solutions... in /etc/cron.hourly/plesk-php-cleanuper, either:
* raise the limit on open files with e.g. "ulimit -n 102400", before the find command.
OR
* change "-execdir" to "-exec", which doesn't have this bug (if you have untrusted users on your machine be aware of the security implication of -exec... read the manpage).
OR
* remove the section "! -execdir fuser -s {} \;" entirely. It's just checking whether any process has the file open at the moment. This won't - and shouldn't - prevent it from being deleted, and subsequent accesses by httpd will just find that the session has been deleted. perfect. So the complete line would be:
[ -x /usr/lib64/plesk-9.0/maxlifetime ] && [ -d /var/lib/php/session ] && find /var/lib/php/session -depth -mindepth 1 -maxdepth 1 -type f -cmin +$(/usr/lib64/plesk-9.0/maxlifetime) -delete
Be aware that after you make any of these changes, then the first time this script runs and
works on a large directory (e.g. 1million+ files), you could bring your server to its knees for some time as it chews over all those delete operations. I wrote a one-off script to remove them gradually in the background before installing the corrected version of plesk-php-cleanuper.