Mdadm is my favorite friend but there is something that annoys me terribly – periodic inspections and resink health of the RAID array- for example there is data in bad sectors, which in turn crushes the machine from to IO. In general, after picking, I found the culprits – crowns that usually start around 1pm every Sunday. The idea is clear – assurance that the array is in perfect condition and there is no drama with the information. This is good, but I see a lot every week, so I reconfigured it to run every first date of the month.
For Redhat based derivatives the path to the crown is /etc/cron.d/raid-check. For Debian based distros, the path is /etc/cron.d/mdadm. Crowns, in turn, call bash scripts /usr/sbin/raid-check for CentOS etc and /usr/share/mdadm/checkarray for Debian and friends. Parameters to the scripts are taken from /etc/sysconfig/raid-check or respectively /etc/default/mdadm where the check can be completely banned, which is not very clever as an idea.
Some programmers will simply never learn to write fluently in RFC. I noticed a lot of errror_log files in which a huge number of stupid warnings and notices for non-compliance with PHP standards had accumulated.. In general, it is difficult to explain to the consumer, that the code he put is naughty and needs to be fixed. In general, I've noticed that users don't care about error logs after their code works. Basically, a radical approach is to completely stop the error_log files and who wants to play them, but in general it will create discomfort for many users. That is why I am stepping up to an approach 2 – admin superpowers or 1 red bash. Search for files named error_log larger than 5MB (here I leave my value higher even though 1MB is more than enough) and deleting them weekly. The effect in question is achieved elementary with find
find /home/ -name error_log -size +5M -type f -delete
All that remains is to run into a crown to be performed once a week and we have a very persistent solution. In my case it seems ok in 1 hours every Sunday.