Dear all i am facing a storage problem.
i cannot receive or sent or delete any mail
i get logs:
Jul 11 12:35:55 vmi690388 postfix/postdrop[4412]: warning: mail_queue_enter: create file maildrop/977093.4412: No space left on device
Jul 11 12:36:00 vmi690388 postfix/cleanup[4383]: warning: mail_queue_enter: create file incoming/326262.4383: No space left on device
Jul 11 12:36:05 vmi690388 postfix/postdrop[4412]: warning: mail_queue_enter: create file maildrop/977647.4412: No space left on device
Jul 11 12:36:10 vmi690388 postfix/cleanup[4383]: warning: mail_queue_enter: create file incoming/327137.4383: No space left on device
Jul 11 12:36:15 vmi690388 postfix/postdrop[4412]: warning: mail_queue_enter: create file maildrop/978077.4412: No space left on device
Jul 11 12:36:20 vmi690388 postfix/cleanup[4383]: warning: mail_queue_enter: create file incoming/330699.4383: No space left on device
Jul 11 12:36:25 vmi690388 postfix/postdrop[4412]: warning: mail_queue_enter: create file maildrop/978460.4412: No space left on device
Jul 11 12:36:30 vmi690388 postfix/cleanup[4383]: warning: mail_queue_enter: create file incoming/331072.4383: No space left on device
Jul 11 12:36:35 vmi690388 postfix/postdrop[4412]: warning: mail_queue_enter: create file maildrop/978892.4412: No space left on device
The strange is that i have almost 50% free space in my contabo vps server.
I also have some errors due to no space left:
2022-07-11 12:43:44.804036 [ERROR] [999] [:HTTP2-1#] [CACHE] createEntry failed for update stale.
2022-07-11 12:44:10.470692 [ERROR] [998] [:HTTP2-9#] [CACHE] createEntry failed for update stale.
2022-07-11 12:44:20.133767 [ERROR] [1003] [:HTTP2-1#] [CACHE] createEntry failed for update stale.
2022-07-11 12:44:22.338434 [ERROR] [997] [:HTTP2-1#] [CACHE] createEntry failed for update stale.
2022-07-11 12:44:54.644071 [ERROR] [1003] [:HTTP2-1#] [CACHE] createEntry failed for update stale.
Any idea ?
Thanks for the tip.
I cleaned the var/tmp folder but still facing same problem. Rebouted also the droplet.
Is there another temp folder that i should empty ?
you can do { find / -xdev -printf '%h\n' | sort | uniq -c | sort -k 1 -n; } 2>/dev/null to list the directory with the most inode at the bottom. Show last 5 lines.
No, that’s the php session folder, there’s a cron job to delete php session ( /usr/local/CyberCP/bin/cleansessions run it now ) but it’s not really that aggressive at deleting, some people here divide the time by 60, which should be the default and is the easy fix, I guess very few people run high traffic sites if they never hit that problem.
It’s better to move that stuff in /tmp or /dev/shm ( which is in RAM/SWAP ). Check your php.ini the OS will take care of cleaning /tmp.
I never understood that decision since cyberpanel already use /tmp for php sockets, and ols use /dev/shm for it’s socket.
You can probably delete everything in /var/lib/lsphp/session/lsphp74, it depends on your use case obviously. If you need very long session or very fast session, you can save them to mysql/redis for that.
Cache has nothing to do with it, or size, it’s just 2.7 millions very small files that should have been deleted.
I get this message:
-bash: /usr/bin/rm: Argument list too long
i also tried the: rm -rf /var/lib/lsphp/session/lsphp74/*
same message: -bash: /usr/bin/rm: Argument list too long
… I mean I can’t give a full linux class, you can google those things, you can delete the whole folder and recreate it, or just go inside that folder and type :
find . -type f -delete
will depend on your distro and how they view things, find might need inodes to work too.
As for the future, you need to check what’s wrong with deleting session, because 2.7 millions files in a single folder is not sustainable, at all, it’s a major performance bottleneck and increasing inodes will just make it worse and you’ll always run out of inodes.
It gets session_time from php.ini ( which is set to 14400 ) which is in SECONDS.
And then it looks for files older using find -cmin which is in MINUTES.
14400 seconds is 4 hours, 14400 minutes is 10 days. So sessions don’t get deleted until 10 days. For low traffic, that’s not really an issue, but high traffic that’s a killer. Dividing session time by 60 fix the issue. I’m too lazy to file a bug report @usmannasir