Hi there, On Thu, 17 Mar 2022, Stephen Scotter via clamav-users wrote:
I noticed Clamd has unexpectantly died on two [VMs] ... System1 Virtual Machine CPU : 1 socket / 2 cores RAM : 2GB Ram ... OS : Debian 10 / buster Clam : ClamAV 0.103.5/26484/Thu Mar 17 08:28:38 2022 Mar 13 13:14:27 System1 clamd[9495]: LibClamAV Warning: fmap_readpage: pread fail: asked for 901703 bytes @ offset 4096, got 0
This certainly seems to be saying that ClamAV asked for 900kB of RAM and that it was disappointed. If there's only 2G in the VM then I'd expect this to happen more or less on every database reload if you're (a) using the official signature database and (b) allowing clamd to scan while reloading signatures - because it uses about 1G of RAM for the official signatures and twice as much while reloading, unless you configure it otherwise.
System2 Virtual Machine 1 socket / 2 cores 4GB Ram (This is our standard allocation; This VM isn't in production yet and isn't doing anything) OS : Debian 11 / bullseye Clam : ClamAV 0.103.5/26484/Thu Mar 17 08:28:38 2022 Mar 9 19:56:17 System2 clamd[541]: LibClamAV Warning: fmap_readpage: pread fail: asked for 455239 bytes @ offset 450560, got 0 ... This feels like it could be related to a lack of RAM?
Not so easy to explain if you have 4G of RAM unless it's doing something else which uses quite a chunk of RAM too.
Mar 9 19:56:17 System2 systemd[1]: clamav-daemon.service: Consumed 20min 43.611s CPU time.
OTOH if it isn't doing anything, how is it that clamd has managed to use more than twenty minutes of CPU? Are you perhaps scanning some large files? What does 'top' say? We only scan mail, never filesystems, and the mail server limits the size of anything which might be scanned to a few megabytes. Free RAM is monitored by Icinga, giving confidence that nothing unexpected is happening. TTBOMK I've never seen the warnings from LibClamAV that you're seeing. I've just grepped 18 months worth of clamd logs and found no example of 'readpage'. We use a Raspberry Pi4B as a clamd server, it has 4GB of RAM. It's running several other memory-hungry processes, although clamd tops the list at about 1.6GB resident - we use dozens of third-party signature databases. Most of the time free RAM hovers around 2.2GB. During signature database reloads that drops by around 1G for a minute or so. There are of course other reasons why clamd might die; I normally only see that when I'm exprimenting with Yara rules. Generally if I get a rule horribly wrong[*] then after reloading the signatures clamd will crash when it next tries to scan something. IMO it's rather too easy to crash it that way, but I haven't found any other reliable way to crash it and under 'normal' circumstances. When I'm not messing about with Yara rules, I find it very stable. [*] e.g. failing correctly to pair the curly braces... -- 73, Ged. _______________________________________________ clamav-users mailing list clamav-users@lists.clamav.net https://lists.clamav.net/mailman/listinfo/clamav-users Help us build a comprehensive ClamAV guide: https://github.com/vrtadmin/clamav-faq http://www.clamav.net/contact.html#ml
