I have a user that is sending themselves e-mails containing attachments of web server logs on the last few days of each month that appear to be very well compressed. When this happens, clamd seems to overheat.
88457 root 59 0 319M 207M RUN 8:28 90.82% 90.82% clamd Notice the amount of memory that clamd is occupying and the CPU utilization %. Our mail server caps individual e-mails at 30MB total size. The uncompressed attachment files take up over 200MB all combined. After the files get to about 200MB total # ls -al /var/tmp/clamav-09edc1e686eae7ca/ total 190534 drwx------ 3 root wheel 512 Dec 29 12:41 . drwxrwxrwt 8 root wheel 512 Dec 29 13:05 .. -rw------- 1 root wheel 97486643 Dec 29 12:55 comment.html -rw------- 1 root wheel 97486643 Dec 29 12:55 nocomment.html drwx------ 2 root wheel 512 Dec 29 12:41 rfc2397 -rw------- 1 root wheel 0 Dec 29 12:41 script.html It seems to stop, then I get this error in my amavis-new logs: Dec 29 12:56:58 host /usr/local/sbin/amavisd[89023]: (89023-01) (!)do_uncompress: Error running decompressor /usr/bin/gzip -d on p001, exit 1 at (eval 68) line 562. Dec 29 12:57:14 host /usr/local/sbin/amavisd[89023]: (89023-01) (!)Decoding of p006 (ASCII text, with very long lines) failed, leaving it unpacked: do_ascii: timed out After this, it starts to make another attempt at decompressing the files from scratch. What is advised to be done to prevent a mail server from being brought to its knees by something like this? Does this look like something that amavisd is doing or clamd? -- Mark Hennessy _______________________________________________ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://lurker.clamav.net/list/clamav-users.html
