Fajar A. Nugraha wrote:
Hi,
I got these errors on Linux Console running ClamAV 0.80 :
LibClamAV Error: cli_calloc(): Can't allocate memory (131282 bytes). calloc_problem: Cannot allocate memory
LibClamAV Error: cli_calloc(): Can't allocate memory (131282 bytes). calloc_problem: Cannot allocate memory
LibClamAV Error: cli_calloc(): Can't allocate memory (131282 bytes).
The thing is, clamd didn't die when it happens. I thought new implementations of libclamav was supposed to die
when it's unable to allocate memory (e.g. to make it work with daemontools?)
Since when was this decided to be a good idea? Suppose I am running clamd under ulimit to control its memory usage. I dont want it to die on out of memory issues caused by scan jobs, making it unavailable for possible jobs that wont cause OOM and terminating all other scanning jobs. I want it to recover gracefully and continue scanning other jobs. Assuming there is no memory leak, recovering gracefully means possibly aborting the current scanning job (or not expanding the current file format or similar task) and leaving all the other jobs and threads alone.
Perhaps this should be configurable for the folk who want clamd to exit on memory alloc failure and those who do not?
If you keep bumping into an OOM for normal operation your limit is too low or clamd is losing memory. Constantly restarting clamd can cause a fair amount of missed/canceled jobs or scanning delays.
Constantly restarting any daemon meant to run continuously is poor operational procedure.
Even with clamscan, dieing on OOM while doing a large recursive filesystem scan would be a real PITA. Just back off the offending job and continue with the rest. The only other way to reliabily scan every scannable file is to call clamscan on them one by one like find . -exec clamscan {}.
I also dont particulary think its wise for a library to include any calls to exit. Libraries you link your program to should not terminate your program without your direct permission.
In fact, the only benefit this brings is to limit the impact of memory leaks. Which are bugs and should not dictate normal program behavior.
All other cases of OOM should be handled gracefully, assuming the program has gotten itself off the ground already.
Regards,
Fajar _______________________________________________ http://lists.clamav.net/cgi-bin/mailman/listinfo/clamav-users
_______________________________________________ http://lists.clamav.net/cgi-bin/mailman/listinfo/clamav-users
