On Tue, 14 Sep 2004, Devin Carraway wrote: > On Tue, Sep 14, 2004 at 11:58:26AM +0100, Mark Powell wrote: > > scanning time. Seems like an "alarm 0" should be in there? > > I observed this with clamav a while back, thus learning that I'd forgotten to > impose a maximum size in the clamav configuration. I added support for a size > limit to the clamav plugin also, since there's no point extracting what you're > not going to scan. If you're only looking for viruses, imposing a size limit > is generally a good idea --
We impose a limit of 50MB on incoming email. All virus scanners are cpu, memory and filesize resource limited. However, I see no reason why the smtp conversation timeout should be further imposed upon the whole scanning procedure. Applying a wall clock timeout on this procedure seems rather poor form. > and if you're trying to protect windows users, > they need a scanner of their own anyway, so scanning big files is of minimal > use. Unfortunately at a University, users need/wish to send each other huge .xls, .doc, .etc files. They have now learnt to zip them to get them below 50MB! These large files have to be virus scanned, but can only get through when the relays are not too busy to take longer than our 120s smtp conversation timeout. There should be an "alarm 0" in there. > More generally, every dropped-tmp situation I've looked into has been > attributable to SIGALRM. Most often it's from spamassassin or from clamav. I've put the "alarm 0" into my installation and now qmail-scanner can work up to it's resource limits, as expected. The files left in tmp have now dropped dramatically. The remaining files are from instances of qpsmtpd that didn't catch a SIGALRM. > One approach I've found generally workable in apps with many abort-points is > to have routines add their tempfiles to a list, the contents of which are > unlinked on exit. Something similar could be applied by adding a reaper to > the transaction object. Okay, so it conceals the symptoms, but finding out > you're hitting SIGALRM by filling up tmp is even worse. This seems like a fair idea. Why knowingly leave those files in tmp when you could quite easily remove them? Cheers. -- Mark Powell - UNIX System Administrator - The University of Salford Information Services Division, Clifford Whitworth Building, Salford University, Manchester, M5 4WT, UK. Tel: +44 161 295 4837 Fax: +44 161 295 5888 www.pgp.com for PGP key
