Re: [AMaViS-user] Re-animated /var/amavis

Daniel 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?

See http://www.ijs.si/software/amavisd/#faq-gen
This may explain most everything.

> 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-.

In the future I would limit the allowed message size in postfix:

message_size_limit = 15728640
# 15MB for example

> 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.

> 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. @.@

> 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.

> 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?

There must be timeout/timing issues. I would look through the logs for
evidence of this. I guess Postfix does not think the transaction has been
completed (I'm thinking that when it first sent a message to
amavisd-new, it did not get a reply from amavisd-new in a timely
fashion). I'm not sure, but I suppose it's possible amavisd-new just
kept humming along, and eventually delivered the message back to
Postfix (on the output side of amavisd-new), but Postfix had given up on a reply
from amavisd-new some time ago (on the input side). Following the sequence
of events in the logs would be interesting. Raise $log_level to gain more
details if needed. To end the agony, I would look in your log to obtain the
postfix queue_id's of the messages that are stuck in the deferred queue
(the ones that are From: the offending sender, and To: the ones she sent
them to, and have timed out). Use the mailq command to help with that. Then
I would delete them from the deferred queue, one by one.
postsuper -d queue_id

Gary V



-------------------------------------------------------
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
AMaViS-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/...fo/amavis-user
AMaViS-FAQ:http://www.amavis.org/amavis-faq.php3
AMaViS-HowTos:http://www.amavis.org/howto/