Apr 24 15:37:06 ucs-7413 clamd[737]: Wed Apr 24 15:37:06 2019 → SelfCheck: Database status OK.
Apr 24 17:08:47 ucs-7413 clamd[737]: Wed Apr 24 17:08:47 2019 → SelfCheck: Database status OK.
Apr 24 18:19:34 ucs-7413 clamd[737]: Wed Apr 24 18:19:34 2019 → SelfCheck: Database status OK.
Apr 24 19:30:27 ucs-7413 clamd[737]: Wed Apr 24 19:30:27 2019 → SelfCheck: Database status OK.
Apr 24 20:30:27 ucs-7413 clamd[737]: Wed Apr 24 20:30:27 2019 → SelfCheck: Database status OK.
Apr 24 21:34:56 ucs-7413 clamd[737]: Wed Apr 24 21:34:56 2019 → SelfCheck: Database status OK.
Apr 24 22:34:56 ucs-7413 clamd[737]: Wed Apr 24 22:34:56 2019 → SelfCheck: Database status OK.
Apr 24 23:40:39 ucs-7413 systemd[1]: clamav-daemon.service: Main process exited, code=killed, status=9/KILL
Apr 24 23:40:39 ucs-7413 systemd[1]: clamav-daemon.service: Unit entered failed state.
Apr 24 23:40:39 ucs-7413 systemd[1]: clamav-daemon.service: Failed with result ‘signal’.
There is nothing to find in the clamav.log and some inconsequential entries in syslog:
Apr 24 22:09:54 ucs-7413 freshclam[699]: Reading CVD header (main.cvd): WARNING: Can’t get information about db.local.clamav.net: Temporary failure in name resolution
Apr 24 22:09:54 ucs-7413 freshclam[699]: WARNING: Can’t read main.cvd header from db.local.clamav.net (IP: )
Apr 24 22:10:31 ucs-7413 freshclam[699]: WARNING: Can’t query current.cvd.clamav.net
Apr 24 23:40:39 ucs-7413 systemd[1]: clamav-daemon.service: Main process exited, code=killed, status=9/KILL
Apr 24 23:40:39 ucs-7413 systemd[1]: clamav-daemon.service: Unit entered failed state.
Apr 24 23:40:39 ucs-7413 systemd[1]: clamav-daemon.service: Failed with result ‘signal’.
After increasing the RAM size in the virtual machine (vSphere) to 6 GB, the deamon runs a bit longer.
It seems as if clamav reserves memory but does not release it.
However, this behavior is also in the previous ucs version (2-3 weeks) to determine.
Before no amavisd errors have occurred.
Because the error messages are sent to a special account, I just did not notice before.
if it gets killed due to to few memory you will see “oom” messages (Out Of Memory) in the log files. If you do not see them (and your swap space is only used a little bit) it is not due to oom.
Well…I do not know where you got the information of not using swap in a virtual makes sense. Whoever told you this I would not listen to any advice this guy is giving you in the future.
You might not have seen any oom message because of looking at wrong places but I am pretty sure an oom happened. Even in your short output by comparing first and last line:
procs -----------memory---------- —swap-- -----io---- -system-- ------cpu-----
r b swpd free buff cache si so bi bo in cs us sy id wa st
0 0 0 745944 196148 1119284 0 0 247 250 248 300 13 3 83 1 0
[...]
0 0 0 188700 196036 983400 0 0 0 184 114 277 0 3 95 2 0
I see a decrease of free memory from 745,944 to 188,700 so around 200M in 30 seconds…
Do you need further prove of the issue being memory related? Yes, there are still buffers and cache available but I could image this will go down, too.
We already had several systems where customer installed a load of apps (including ClamAV) and wondered why the system is so slow or behaving strange.
Sorry guys, give a UCS server enough memory an you will have not troubles. Especially, give it SWAP!
When swap is available, increase your memory (RAM) until under usual load the vmstat shows nearly just “0” in si and so column.
Ignore the swap usage, si and so is important. Check this article.
Oh, did I mention: create swap and increase memory!