Session files not being removed #1259
Open
Comments
I had the exact same issue. A LOT of sess_* files under many tmp directories I'll switch session.gc_probability to 1 and hope it helps |
I have the same issue, is the session.gc_probablity to 1 the only option out there? |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Operating System (OS/VERSION):
root@painel:~# cat /etc/issue
Debian GNU/Linux 8 \n \l
root@painel:~# uname -a
Linux ****** 3.16.0-4-amd64 #1 SMP Debian 3.16.43-2 (2017-04-30) x86_64 GNU/Linux
VestaCP Version:
root@painel:~# dpkg -l | egrep -i vesta
ii vesta 0.9.8-17 amd64 Vesta
ii vesta-nginx 0.9.8-16 amd64 Vesta Nginx
ii vesta-php 0.9.8-17 amd64 Vesta php-fpm
Installed Software (what you got with the installer):
(apache+nginx) + php + exim + bind + devecot + iptables
Steps to Reproduce:
Default installation without any vestacp customized configuration.
Yesterday that server had 100% inode usage and all user services stopped to work. I saw 3 millions of php session files created and not removed. So, because everything stopped to work, I removed some of them manually with:
find /home/*/tmp -type f -name 'sess_*' -ctime +5 -delete
Related Issues/Forum Threads:
I found same question here:
https://forum.vestacp.com/viewtopic.php?t=10266
I observed session.gc_probability configuration is zero (default vestacp configuration), but I really think we can not use zero in this configuration.
And I found that value is 1 on sources:
https://github.com/serghey-rodin/vesta/blob/0.9.8-9/src/rpm/conf/php.ini
Other Notes:
I changed manually session.gc_probability to 1 and restarted nginx/apache and now I am seeing 1.4mi of php session files at /home/admin/tmp/ decreased to 129703. I think its too much either, but much better of course.
The text was updated successfully, but these errors were encountered: