Yesterday I had an interesting issue, where one of the colo’d servers I manage, became almost unresponsive. After what felt like an age I was finally logged on to the failing box in question. It quickly became apparent that the ClamAV application clamscan was being spawned multiple times and consuming all available memory and causing the server to swap until it ran out of swap (in fairness the server is lacking in the memory department).
I initially thought it might be related to the AV scanning of emails, but the server wasn’t handling a lot of email at the time. I then started to dig deeper and as the clamscan processes were owned by apache I started to question whether or not spamassassin was doing some weird and wonderful scanning by way of a clamav plugin. Not the case. In the end it turns out that it was being triggered by the ownCloud 9.x installation on the same server. At some point, Antivirus integration was enabled within ownCloud (I believe prior to ClamAV being installed). It also happened that there was about 1.6GB of data being uploaded to that server which was triggering all of the clamscan processes.
Clamscan is (by ownClouds own admission) not the best option on grounds of performance and reliability, which does beg the question; if it’s not the most suitable way to use ClamAV in an ownCloud installation, why default to that setting???
For me I uninstalled ClamAV which in turn prevented the clamscan app from being executed and I was then able to access ownCloud again to make the necessary changes to the settings so that clamscan was not used.
Changing the method from Executable to one of the Daemon methods is advisable as a minimum. After changing to the daemon (socket) method it was a more controlled use of the av scanning and I haven’t so far seen any ill effect.