Bullshittery continues. This time around, absolutely innocent, clamav is root cause. For once not incompetent idiot, but piece of software. IDK if that makes me happy or upset.

So our email server that I configured and took care of died. RIP. Damn, better put it back together ASAP. So Im under pressure, while still pissed at everything that I ranted before (actually my last 2 rants were throttled, and in total all of that happened past 60 minutes but devrant rate limiting) I start auditing logs. You imagine, we kindda need it NOW, and it's second time last month clamav is pulling stunts and MTA refuses (properly) to work without antivirus. So pressurized, I look at logs, what the fuck went wrong.

clamav deamonize() failed - cannot allocate memory

Hmm. Intresting, but sounds like bullshit. I know server is quite micro becouse they wanted to save on costs as much as possible, but it has well over half a gig free ram just before it crashes (like 800MB) with that message. Is it allocating almost gig in one call or what? Looked carefully at trusty htop while it was starting, and indeed, suddenly it just dies with quite a bit of ram free, almost as much as it weights already. And I remember booting it up when I was configuring it, and it had fair bit of headroom.

Google, help me friend... Okay, great, so apparently at some point clamav loads virus DB into ram (dafuq?), and than forks, which causes spike of 2x the ram usage, and than immidietely frees it up.

Great, that sounds like great design decision... At least I know, I can just slap on SWAP file, restart it and call it a day.

It worked, swap file is almost empty (used 15megs, 900 megs free ram, whatever).

That leaves me wandering, who figured out to load DB to ram? That means pretty much that clamav will eat a little bit more ram each vir db update, and that milisecond "double ram" spike will confuse innocent people who just wanted to run clamav and it worked last *long period of time* and now crashes without warning without any changes to configuration.

Maybe there is logical explanation, I want to know it.

  • 0
    Umm.. For some reason I was sure fork() does not double ram usage of parent process. It rather uses parent's data and does CoW - only then ram usage grows. Please correct me if i'm wrong
  • 0
    Try to strace clamav -- see where the lack of memory is hitting.
  • 1

    For me it dosen't make sense too, look here:

  • 0
    I'm not sure why ClamAV (more specifically clamd) loads the database into RAM _before_ forking.
    That ClamAV must load it into RAM (ideally after forking) is out if question, as the ClamAV database is just .tar.gz of the human readable signatures, a form whar ClamAV cannot be easily work with.
    The last time I used it (a few of months ago), the total RAM usage was 'just' 250MB for the clamd process...
  • 0
    @sbiewald wow is that some sort of clamAV lite or sth? O,,,O
  • 1
    @DubbaThony I have no idea, as clamd currently uses ca. 780 MB on my machine. I'm wondering what happened.
    One link on the serverfault answer you gave us, showed that ClamAVs optimizer might try to optimize the database too heavily in certain conditions - sacrificing memory for speed.
  • 1
    Mmm... Perhaps they meant to load the DB in a shared memory and then allow both processes access to it?
  • 0

    But clearly it dosent work.
Add Comment