2

On a Debian 10 server I have this problem with clamav:

root@vps:~# clamscan -r -v --stdout /
Killed

You see I use the verbose flag but that does not give me any information. In years of using clam I have not had this problem. I know it's not a database problem:

root@vps:~# freshclam
Sun Mar  1 00:18:39 2020 -> ClamAV update process started at Sun Mar  1 00:18:39 2020
Sun Mar  1 00:18:39 2020 -> daily.cvd database is up to date (version: 25737, sigs: 2201376, f-level: 63, builder: raynman)
Sun Mar  1 00:18:39 2020 -> main.cvd database is up to date (version: 59, sigs: 4564902, f-level: 60, builder: sigmgr)
Sun Mar  1 00:18:39 2020 -> bytecode.cvd database is up to date (version: 331, sigs: 94, f-level: 63, builder: anvilleg)

Please suggest steps to test.

EDIT: This is an OpenVZ VPS with 512MB RAM.

EDIT: strace shows killed by SIGKILL but that doesn't tell me much.

2
  • Try asking on unix.stackexchange.com
    – Massimo
    Mar 21, 2021 at 3:11
  • 1
    ClamAV usually requires fair amount of RAM to execute. Check with dmesg, probably it's oom_killer who killed it. Mar 23, 2021 at 10:21

3 Answers 3

5

As mentioned in some of the other comments, the likely culprit is oom_killer or oom_reaper. You can check for this by tailing /var/log/messages while running clamscan. Ex:

# Kick this off in a console and keep an eye on it
sudo tail -f /var/log/messages

# Run this in a separate console
sudo clamscan /etc/

In my case, clamscan died after a few seconds, and messages such as the following appeared within /var/log/messages:

kernel: oom-kill:constraint=CONSTRAINT_NONE,nodemask=(null),cpuset=/,mems_allowed=0,global_oom,task_memcg=/user.slice/user-1000.slice/session-1.scope,task=clamscan,pid=1520,uid=0
kernel: Out of memory: Killed process 1520 (clamscan) total-vm:836952kB, anon-rss:540640kB, file-rss:0kB, shmem-rss:0kB, UID:0 pgtables:1248kB oom_score_adj:0
kernel: oom_reaper: reaped process 1520 (clamscan), now anon-rss:0kB, file-rss:0kB, shmem-rss:0kB

So, if you observe the same thing, then you should try allocating more resources (ie: memory) to the machine instance.

0

Make sure /etc/ld.preload.so has no entries, any entry in that file would be suspicious. Verify modified timestamps on all files in /etc.

Try strace freshclam to gather more information.

6
  • /etc/ld.preload.so does not exist. Anyway you are going in a different direction than my question. If strace output is intelligible to you then all I have to say brother is 001011010001010. I tried that before and it does not show me anything that indicates an error in words. Mar 4, 2020 at 9:37
  • In case clamav is simply killed/dies it is suspicious. I'm not aware of any other useful debug information in this case other than the strace output which shows calls at syscall level.
    – hargut
    Mar 4, 2020 at 16:50
  • As you updated the question above it seems that in your environment there is something that sends a SIGKILL to clamav. Behaviour like that I've so far only seen on compromised systems. Typically in combination with some mechanism to shade that activities (e.g. preloaded libraries in /etc/ld.preload.so) which hide e.g processes in ps outputs, files in directory listings, ....
    – hargut
    Mar 4, 2020 at 16:53
  • It is a fresh install so that is unlikely but not impossible. Mar 6, 2020 at 6:07
  • It might as well be an OOM kill or something different. SIGKILL is pretty clear. Within your provided details there is no information on why it was issued to the clamav process.
    – hargut
    Mar 6, 2020 at 14:35
0

its an old thread but mot likely ppl will come to it. this happens because of not having enough memory on system. use command free -m and check if you have swap file enabled, if not enable it and give it min 2 GB and try again and error will disappear.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .