Out of the previous CentOS Exim Advanced Configuration Primer Tutorialโs analysis phases โฆ
- hard disk space
- hard disk inode count (for Linux and unix web servers)
โฆ that latter one raised its-not-so-good-looking head for two days last Sunday (in the middle of the Sydney, Australia day) and Monday (up until resolving around 11am Sydney time). Not that I immediately knew that. Our symptoms of โsomething wrongโ consisted of โฆ
- all parts of Apache web server (for RJM Programming) websites working, including MySql ones
- cPanel hung
- FileZilla sftp got connection resets
โฆ which is tempting to ignore, and hide the old noggin in the stuff that falls through the hourglass.
Luckily, though, my torpor was disturbed by needing to sftp an image over to the web server to complete yesterdayโs tutorial.
Now, itโs inconvenient that the title gives โthe general game awayโ about the source of the issue, but it would be an imaginative operator indeed who could jump to this โeven general conclusionโ from these symptoms, without getting access to this web server. And on reflection, had we used Power Management to see whether that would have had a chance of fixing the issue, it would have been a waste of time.
So what did we do first on Sunday? Well, we could still log in via ssh and on the RJM Programming web server, went โฆ
# service sshd restart
Stopping sshd: [ OK ]
touch: cannot touch `/var/lock/subsys/sshd': No space left on device
- df -k /
- df -i /
โฆ as per โฆ
# df-k /
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/sda3 133526580 112886392 13860736 90% /
root@vs-rmetcalfe [~]# df -k /tmp
Filesystem 1K-blocks Used Available Use% Mounted on
/usr/tmpDSK 544256 328968 187640 64% /tmp
root@vs-rmetcalfe [~]# df -k /var
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/sda3 133526580 112886456 13860672 90% /
root@vs-rmetcalfe [~]# df -i /
Filesystem Inodes IUsed IFree IUse% Mounted on
/dev/sda3 8478720 8478720 0 100% /
โฆ to arrive at โthere is an inodes quota running out issue with the RJM Programming web server hard diskโ.
So what did we do later on Sunday? We still could, believe it or not, from an already open FileZilla session, delete a goodly number of web server files, which we (recursively) did to get some thousands of inodes to become available again. That left the RJM Programming web server fully functional as we went to โshut eye placesโ. We gave the web server one task (via our Linux Disk Usage cPanel Heads Up Tutorial) to do for these sleeping hours โฆ
# du -a / 2> /dev/null | sort -n -r | head -15
โฆ but it petered out, alas. It is a very intensive โaskโ, after all. So this takes us to Monday, where we woke up to โฆ
- hard disk space
- hard disk inode count (for Linux and unix web servers)
โฆ back to the original issue, again.
So what did we do on Monday? Well, amongst the research we lobbed onto this useful link, thanks, that got us to go โฆ
find / -ctime -1 -print
โฆ to get a list of files created over the last day. And that was the breakthrough, really, for us, as it lead us to seeing in that list thousands of entries for the filespec โฆ
/home/virtfs/rjmprogr/home/rjmprogr/public_html/zencart/cache/myDEBUG-*.log
โฆ and we noticed, after another round of file deletions to be okay, temporarily, again, when going through a few cycles of โฆ
# ls -clt /home/virtfs/rjmprogr/home/rjmprogr/public_html/zencart/cache/myDEBUG-*.log
# ls -clt /home/virtfs/rjmprogr/home/rjmprogr/public_html/zencart/cache/myDEBUG-*.log
# ls -clt /home/virtfs/rjmprogr/home/rjmprogr/public_html/zencart/cache/myDEBUG-*.log
โฆ each list would get considerably longer over the length of time it took to list the previous! Runaway train had us gobsmacked! Eventually, though, we tweaked to โthe short term solutionโ โฆ
# ksh -c 'for i in `find /home/virtfs/rjmprogr/home/rjmprogr/public_html/zencart/cache/ -name "myDEBUG-*.log"`; do rm -f $i; done'
# df -i /
Filesystem Inodes IUsed IFree IUse% Mounted on
/dev/sda3 8478720 8428558 50162 100% /
# df -i /
Filesystem Inodes IUsed IFree IUse% Mounted on
/dev/sda3 8478720 8429300 49420 100% /
โฆ yayyyyy!!! (with a caveat of โjust relief for now but must find the ultimate reasonโ) โฆ but there were some back again on the next โฆ a growing list again โฆ plus the RJM Programming ZenCart eCommerce website came up with error message โWARNING: An Error occurred, please refresh the page and try again.โ โฆ mesmerized, we repeated the listings, watching the list grow, until it occurred to us, encouraged by that previous link talking about the error could be related to the MySql ZenCart database, to โฆ
# cat /home/virtfs/rjmprogr/home/rjmprogr/public_html/zencart/cache/myDEBUG-1575848271-674789.log
[09-Dec-2019 07:37:51 Australia/Perth] PHP Fatal error: 145:Table './rjmprogr_zencart/sessions' is marked as crashed and should be repaired :: select value
from sessions
where sesskey = '42f9199e81e8c1eeb411921161c67ab9'
and expiry > '1575848271' in /home/rjmprogr/public_html/zencart/includes/classes/db/mysql/query_factory.php on line 101
โฆ giving us the long term remedy โฆ
- get into cPanel
- search for phpMyAdmin option, and click it
- access the rjmprogr_zencart database (and see that sessions table is indeed marked as crashed)
- within SQL tab textarea type โฆ
REPAIR TABLE sessions
โฆ click the GO button โฆ successful
โฆ sanity checked in that โthe listโ no longer grows!!! And as for the inodes quota issue โฆ
# df -i /
Filesystem Inodes IUsed IFree IUse% Mounted on
/dev/sda3 8478720 8425232 53488 100% /
โฆ a lot better, especially as this time it only appears to be getting better (ie. IFree stays roughly the same or gets bigger (with our other crontab remedies we have implemented)). And ZenCart works again. What a relief!
Previous relevant CentOS Exim Advanced Configuration Primer Tutorial is shown below.
There are two file resource aspects to watch out for regarding a web server hard disk storage โฆ
- hard disk space
- hard disk inode count (for Linux and unix web servers)
โฆ which can, respectively, be monitored by Linux commands โฆ
- df -k /
- df -i /
On our CentOS rjmprogramming.com.au web server recently we had occasion to do a check of this, and wanted to improve the web server hard disk situation for both measures, picking the /var folder of our web server. So we executed, respectively โฆ
- find /var -xdev -type f -size +100M
- find /var -mtime -1 -ls
โฆ the latter one being a list of files on /var modified in the last day being our idea to try to see what daily log filing might be contributing big time to hard disk inode usage. And thatโs where we found out this way that our Exim Mail Server logs extensively, and that we could do without those in folders off โฆ
/var/spool/exim/msglog/
We tried the latter of two deletion ideas we show below โฆ
- all at once via โฆ
cd /var/spool/exim
find msglog -type f -exec rm -rf {} \; - broken up โฆ via a series of deletions of the ilk โฆ
cd /var/spool/exim/msglog
rm -f A/*
rm -f a/*
Then the next job was to stop Exim remaking these logs and wish to thank this useful link for great advice here, that led to this advice we give โฆ
- log in to WHM cPanel
- in search bar type โEximโ
- click the โExim Configuration Managerโ
- click โAdvanced Editorโ tab (up the top)
- click the blue โAdd additional configuration settingโ button well down the webpage
- click โmessage_logsโ in left hand drop down
- set value of this setting to โfalseโ
- click blue โSaveโ button down the bottom of webpage to complete the steps here
You may find this is a web server configuration of interest to you too.
If this was interesting you may be interested in this too.
If this was interesting you may be interested in this too.