Submitted by mike0810 on Wed, 07/06/2016 - 05:38
On a vanilla Centos 7 with all updates and virtualmin, running five domains with around 30 Mailusers, my Virtualmachine is equipped with 4 2,4GHz Xeon Cores and 8Gig of Ram.
Sometimes, clamscan claims all 4 CPUs to 100% each and fills ALL the RAM and swaps additionally 4-5GB of Ram.
This is a major issue due to the fact that the whole server is inaccessible at this time and as well goes into OOM Killer.
Status:
Active
Comments
Submitted by mike0810 on Wed, 07/06/2016 - 05:45 Comment #1
Seems like after the last webmin/virtualmin update/reboot, the clamdscan server daemon is broken again and the scanning falled back to clamscan which overloads the system periodically. The clamav-daemon is now not configurable again.
status clamav-daemon.service ● clamav-daemon.service - Clam AntiVirus userspace daemon Loaded: loaded (/usr/lib/systemd/system/clamav-daemon.service; enabled; vendor preset: disabled) Active: failed (Result: exit-code) since Mit 2016-07-06 12:39:48 CEST; 1min 9s ago Docs: man:clamd(8) man:clamd.conf(5) http://www.clamav.net/lang/en/doc/ Process: 15724 ExecStart=/usr/sbin/clamd --foreground=true (code=exited, status=1/FAILURE) Main PID: 15724 (code=exited, status=1/FAILURE)
Jul 06 12:39:48 webhost01.frontrail.com systemd[1]: Started Clam AntiVirus userspace daemon. Jul 06 12:39:48 webhost01.frontrail.com systemd[1]: Starting Clam AntiVirus userspace daemon... Jul 06 12:39:48 webhost01.frontrail.com clamd[15724]: ERROR: Can't open/parse the config file /etc/clamd.conf Jul 06 12:39:48 webhost01.frontrail.com systemd[1]: clamav-daemon.service: main process exited, code=exited, statu...LURE Jul 06 12:39:48 webhost01.frontrail.com systemd[1]: Unit clamav-daemon.service entered failed state. Jul 06 12:39:48 webhost01.frontrail.com systemd[1]: clamav-daemon.service failed. Hint: Some lines were ellipsized, use -l to show in full.
Submitted by mike0810 on Wed, 07/06/2016 - 05:59 Comment #2
Seems like enabling the clamav server scanner does not execute properly systemctl enable clamd@scan.service When executing this on the cli, and systemctl start clamd@scan, the server scanner can be enabled.
This config did not survive the last system update/reboot as far as I can tell
Submitted by andreychek on Wed, 07/06/2016 - 09:40 Comment #3
Howdy -- hmm, what is the output of these commands:
rpm -qa | grep clamavmailq | tail -1
Also, now that you've gotten the ClamAV server running, is the performance better?
Submitted by mike0810 on Thu, 07/07/2016 - 05:50 Comment #4
This behaviour was only observed a few times. I can not exactly tell what happened when clamscan claimed such an amount of resources. But there was no large amount of mail in/outflowing at the times things happened, its only a small family email instance.
But sometime, clamscan just runs havoc.
With clamdscan however, I never observed such behaviour.
sudo rpm -qa | grep clamav clamav-filesystem-0.99.2-3.el7.centos.vm.noarch clamav-server-systemd-0.99.2-3.el7.centos.vm.noarch clamav-update-0.99.2-3.el7.centos.vm.x86_64 clamav-server-0.99.2-3.el7.centos.vm.x86_64 clamav-0.99.2-3.el7.centos.vm.x86_64 clamav-lib-0.99.2-3.el7.centos.vm.x86_64 clamav-scanner-0.99.2-3.el7.centos.vm.noarch clamav-data-0.99.2-3.el7.centos.vm.noarch clamav-scanner-systemd-0.99.2-3.el7.centos.vm.noarch
mailq | tail -1 -- 9 Kbytes in 1 Request.
Submitted by andreychek on Thu, 07/07/2016 - 09:52 Comment #5
Yeah it's tough to know what might have been going on there... my best guess, is that there was a big influx of email at the time.
The command line clamscan uses a lot more resources that the server scanner you're using now, so if a bunch of emails came through at once, that could potentially cause that issue.
We'll look into why that service wasn't starting from within Virtualmin, though that sounds familiar, in that it may actually be corrected in the next version being pushed out.
The packages you have installed there look good.
So I suspect you should be in good shape now, though let us know if you see any other issues.