Wanted to add a bit of insight to this convo from the dev side of things:

VirusEvent currently works by forking the existing clamd process into a new, short-lived process that handles execution of the user's script.

This is a legacy design choice and is problematic for a number of reasons--most relevant here is that you will need at minimum 2x the amount of resources clamd is already using to execute the VirusEvent. It was this resource drain, combined with the threaded nature of the old on access code, which led to us disabling the feature (only for on access scanning, not clamd/clamdscan).

From what I can tell, your problem is that the fork system command is failing (code path for that error requires a negative return for fork())--very likely due to lack of resources on the server.

Ideally, we would fix this resource consumption issue on its own, or better, as part of a larger redesign of clamd, but for now--like Ged, I would also recommend increasing memory resources and seeing if that solves the issue.

-Mickey
 
 

On 2020-02-11 11:30:11-05:00 clamav-users wrote:

Hi there,

On Tue, 11 Feb 2020, Tom Ossman via clamav-users wrote:
>>
>>> ... the VirusEvent script (also cleansed).
>>
>> Does the script contain the first two lines as in the version which
>> you sent to me?  If so, remove them.  See the 'man' page for the
>> 'file' utility and use it on your script. :)
>>
>> Are you refering to the comment and shebang? If so, the comment isn't
> there but the shebang is and if that is one of the lines you are refering
> to, correct me if I am wrong but doesn't a script need the shebang to run?

In the script which you attached the shebang line is the third line.
The first two lines were a non-shebang line comment and a blank line.
Obviously the shebang line must be the first line in the real script.
(When I asked you to show us the script, I didn't mean for you to show
us some rough approximation to it. :)

You might want to use full path names for things like 'cat' in the
script so that it doesn't depend e.g. on environment variables which
might not be set.

> ... from what I have observed in the past the memory did not look like
> it was being maxed out.  But spinning up a larger instance with more
> memory is not a big deal.

Please let me know if you have any more information about resources.

We still don't know that this is not a fault in ClamAV itself of
course, but as it appears that at some time the sytem _was_ working,
it seems much more likely to be an issue with your configuration.

-- 

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