[clamav-users] Error: CRITICAL: fmap() failed

[Ben Stuyts]

On 25 Mar 2021, at 19:38, G.W. Haywood via clamav-users <clamav-users at lists.clamav.net> wrote:
> 
> Hi there,
> 
> On Thu, 25 Mar 2021, Ben Stuyts wrote:
>>> On 25 Mar 2021, at 00:32, G.W. Haywood via clamav-users <clamav-users at lists.clamav.net> wrote:
>>> On Wed, 24 Mar 2021, Ben Stuyts wrote:
>>>> On 24 Mar 2021, at 12:14, G.W. Haywood via clamav-users <clamav-users at lists.clamav.net> wrote:
>>>>> On Wed, 24 Mar 2021, Ben Stuyts wrote:
>>>>> 
>>>>>> ... File ‘a’ is a 4.1 GB mbox file. ...
>>>>> 
>>>>> Then don't scan it...
>>>> 
>>>> Possible, but not the first thing that comes to my mind with email folders.
>>> 
>>> You could scan what you put into it.
>> We do of course, using clamav-milter. But if there’s a missing
>> virus definition during mail transfer it will be hopefully detected
>> at a later stage.
> 
> Emphasis on hopefully, and something about a stable door, and do you
> have working estimates of the probabilities?

It happens in around 1 in 100000-200000 delivered msgs.

> And what do you do if,
> when you scan the huge mbox file, ClamAV says it's found something?

I never said that the virus detected is always in a huge mbox file.

> It won't tell you which message is the suspicious one, so you'll be
> playing about with 'formail' or binary searches or whatever, all the
> while wondering who's at risk from this potentially troublesome but
> unidentified message.  And the detection might not even be triggered
> when you split up the messages.  You could waste a *lot* of time and
> energy that way.

Indeed, and this is all known here. So there’s a script for that. I have not seen the problems you mention.

> Of course you know that there are alternatives to mbox format, which
> not only won't involve you in scanning outlandishly big files but also
> give you substantial improvements in performance elsewhere, not to
> mention giving clamd's cache of MD5 digests a chance to do something
> useful (instead of what it's doing for you now - burning CPU cycles to
> no purpose whatsoever).  Another added benefit might be that you could
> get the scanner to actually identify the suspicious message…

Agreed that it is not optimal in that respect, but changing the mail config is not really an option.

> Not that any of this is a recommendation, other than that people think
> real hard about what they're doing.

We try to, thank you.

Ben