On Sat, 2005-10-01 at 02:45, Daniel Bentley wrote:
> My search-fu is apparently weak, as I couldn't find this answer elsewhere.
>
> Simply put, what exactly is the purpose of subdirectories in
> /var/amavis, mainly in the form like
> '/var/amavis/amavis-20050930T192802-19231'? It appears to be the
> location where amavis temporarily stores emails (raw, and separated into
> parts) for processing. What is the average duration for these
> sub-directories?
Ideally for the lifetime of the amavisd process that created them (I
think - but I may be wrong here - it's certainly fairly short).
> The reason: someone thought it'd be a brilliant idea to put a series of
> emails with images through email. We're talking 63M file attachments to
> -each- mail, and enough of these emails to total up to around 2.9 -GIG-.
Put a limit on what messages size people are allowed to send!I set mine
at 10Mb which keeps most of my users happy - and is still larger than a
lot of ISPs!
> We noticed that the email server was acting particularly sluggish, and
> 'top' revealed CPU usage of up to mid 90% and amavisd (running
> amavisd-new 2.3.1, spamd, uvscan, postfix, on Mandrake LE 2005 (aka.
> 10.2)) taking 500-600M of combined memory and swap. In trying to figure
> out where these problems were coming from, I visited the sender of all
> the files (I hate .bmp files more than ever now... -.- ), and she
> informed me that all emails had been sent, and had been received at the
> other end. So I thought, "Okay, I can clean those directories out of
> /var/amavis, maybe that'll help." As there were other sub-directories
> from 2004, I figured amavis might not always clear out temp email
> storage in /var/amavis/amavis-{date}T{number}-{number} sub-directories.
> So I stopped amavis and postfix, and wiped these sub-directories from
> /var/amavis.
These directories get left behind if amavisd doesn't finish processing
them correctly for some reason (error / unclean shutdown etc.)
> Only... the majority of these emails (sent Mon. and Tues., wiped end of
> the working day on Tues.) started showing up again on Wed. o.o; Same
> emails, same dates for the bodies as evidenced in email.txt files,
> showing up aprox. every 30 min. So I wiped these sub-dirs again earlier
> today (Thurs.). In the past few hours, they've been coming back AGAIN. @.@
My guess is they're still in the postfix queue - amavisd doesn't OK
delivery from postfix until it has received an OK from the instance it
passes th scanned message back to. In this case this isn't happening
because amavis is never completing the processing. Hence postfix never
thinks they are delivered, so keeps re-trying every time you restart
postfix/amavisd after cleaning up /var/amavis.
You'll need to have a look in the postfix queue and identify the
offending messages then remove them with
postsuper -d <message-id>
Then clean up /var/amavis and restart amavisd/postfix and all should be
well - but check your maximum message size in postfix's main.cf
> When I initially cleaded out /var/amavis, system usage by amavis and
> overall performance went back to normal. Each time one of these
> sub-directories shows up in /var/amavis again, there's a corresponding
> jump in CPU usage, often back up in the mid-90% range, and the amavisd
> process seems to continually grow in memory usage as more of these
> emails come back from the dead.
Yes - that sounds about what I'd expect if I'm correct in my assumption
above
> Any thoughts/ideas? Am I only exacerbating the problem by fiddling with
> these sub-directories in /var/amavis? If these emails have been
> successfully sent, why ARE they showing back up in /var/amavis like this
> in the first place?
Did the user send them more than once I wonder?
Rgds
Pete
-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
_______________________________________________
AMaViS-user mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/amavis-user
AMaViS-FAQ:http://www.amavis.org/amavis-faq.php3
AMaViS-HowTos:http://www.amavis.org/howto/
