On 10.10.2014 16:11, Jeremy Harris wrote:
> On 08/10/14 21:03, Michael Fischer v. Mollard wrote:
>> - Is there a generic way to limit the running time of a
>> malware/spamassassin scan?
> That feels worthy of an RFE, please. http://bugs.exim.org
Hello,
I read spam.c vs malware.c again and found a hardcoded limit
SPAMD_TIMEOUT and MALWARE_TIMEOUT, each set (via #define) to 120
seconds. The point is that reading spamd's response is done via
> start = time(NULL);
> […]
> /* read spamd response using what's left of the timeout.
> */
> memset(spamd_buffer, 0, sizeof(spamd_buffer));
> offset = 0;
> while((i = ip_recv(spamd_sock,
> spamd_buffer + offset,
> sizeof(spamd_buffer) - offset - 1,
> SPAMD_TIMEOUT - time(NULL) + start)) > 0 ) {
> offset += i;
> }
while reading malware is done with
> /* read report, linewise */
> do {
> i = 0;
> memset(av_buffer, 0, sizeof(av_buffer));
> do {
> if ((bread= ip_recv(sock, &av_buffer[i], 1, MALWARE_TIMEOUT)) < 0)
> return m_errlog_defer_3(scanent,
> string_sprintf("unable to read result (%s)", strerror(errno)),
> sock);
> } while (++i < sizeof(av_buffer)-1 && av_buffer[i-1] != '\n');
in several cases. So it should be sufficient (as a first step) to fix
the ip_recv call in that cases. The next step/enhancement would be
configurable timeouts.
Michael
By the way: The new 'sock' scanner type seems not to use MALWARE_TIMEOUT
at all, but it would exit as the answer buffer will be filled up.
