named.service killed after clamd fail
-
My gut suspicion is that you are running out of ram and processes are getting killed. Have you been looking at/monitoring your ram utilization? Because according to the logs, MySQL was also killed off. 0 -
My gut suspicion is that you are running out of ram and processes are getting killed. Have you been looking at/monitoring your ram utilization? Because according to the logs, MySQL was also killed off.
When I opened the support thread in September, @cPanelLauren and I exchanged about a possible RAM shortage and she indicated that she didn't think that was the problem. I notified A2 to add 2GB RAM just to eliminate this as the potential cause. About every 2 hours since I rebooted the server, clamd has failed and recovered. I still think it is related to that, somehow. The email notification that I receive shows that the top process is spamd and that is only using around 4% of available memory. You ask if I am looking at or monitoring ram utilization. Can you tell me what tools or scripts you use to do this?0 -
Lacking an external monitoring system you could install Munin and check the memory graphs at the times you see the clamd failures. You might consider removing clamd for a few days and see if the problem goes away. You might consider switching the dns server over to NSD or pwerdns which takes up less memory. You should take a look at service manager and make sure that the name server is set to restart on detected failure. 0 -
Lacking an external monitoring system you could install Munin and check the memory graphs at the times you see the clamd failures. You might consider removing clamd for a few days and see if the problem goes away. You might consider switching the dns server over to NSD or pwerdns which takes up less memory. You should take a look at service manager and make sure that the name server is set to restart on detected failure.
Thanks for the info and suggestions0 -
I have been trying to make some sense of the issues that clamd seems to be provoking for a few users. I use CentOS on the desktop with clamd running as a daemon, and often see it using in excess of 1 GB of memory whilst sitting idle. I have not profiled this to see what the peak usage might be under load (either on my desktop box or my servers) since they all have sufficient RAM as to make such testing unnecessary (so far......). Searching through a number of reports of high clamd memory usage, I eventually found an explanation that, to me at least, begins to make some sense, but what I am hypothesising here may be way off track, and not be a fair representation of the issue at all ! If we accept that clamd used to work without falling over, and rationalise that the server is hosting the same number of websites with the same traffic; something must have changed to provoke the out-of-memory events that lead to the damon crashes (and any other related or collateral damage) and we must examine what those changes might have been. There is no single simple answer, but a significant contributory cause would seem to be the ever growing data set that is the malware signature lists. Freshclam updates the main, daily and bytecode signature list (normally every 4 hours) - I am not sure how often on a cPanel installation, but assuredly at least once a day. Combine that with a ClamAV version that is almost always behind the latest release, and therefore possibly unable to make the most efficient use of the newest signatures, AND the ever growing demands from the operating system and from cPanel and its controlled software and daemons (FTP, mail, Apache, DNS etc etc) and you may experience significant out-of-memory events when the right perfect storm of incoming mail needs to be scanned, combined with some other event like backups or heavy SQL queries. I stumbled upon a number of articles expressing the desire for the signatures to be swapped out of memory when the daemon is not using them, or for a facility to only load a partial data set so as to save on the total memory footprint - but the philosophy of the software developers would seem to be that any loading/unloading of the malware signatures would itself create unnecessary disk I/O, and probably use more system resources than just having the signatures permanently loaded into memory. I kinda/sorta see their point, and I have to confess that I don't know enough detail about how the daemon works to make any sensible comments or suggestions. To reiterate a comment I made elsewhere "Nothing stays the same". Even normal updates and upgrades may contribute to a changed memory footprint that will need to be periodically reassessed, and if you have bothered to read this far down the post ....thank you ! Hope this helps. 0 -
@rpvw, thanks for sharing your analysis with this thread. What you've offered makes sense. On my local computers, I suppose I could compare it to the amount of resources Malwarebytes uses during its database updates and scans. My woes on this issue began in mid-May of this year. I may have added a couple of development sites, since then, but traffic is not impacted by these sites. Since most of my development work is done offline using Xampp, the new sites on my VPS are there merely for review and tweaking prior to moving them over to their final destination. Yesterday (October 28, 2018), I uninstalled the ClamAV plugin and reinstalled the latest version through WHM. This morning, there were issues with a duplicate clam database so I resolved that by following the advice on this thread in the forum. I won't know if that solved the problem until tomorrow morning. Another correspondent on this thread suggested installing Munin. I would but I'm afraid it will exacerbate the overuse of memory. I have contacted A2 Hosting and requested a memory upgrade for my Dynamic VPS. I'm not sure if that is the root cause or when the memory upgrade will be scheduled. If there are any revelations to share with the public after cPanel Support has looked things over, I will do so in order to assist others who might be experiencing similar issues. 0
Please sign in to leave a comment.
Comments
8 comments