Amavisd-2.5.3
Solaris 10 10/08
perl-5.8.4
We have a few local patches, which makes upgrading amavisd difficult,
and also makes me worried it is our patches that broke things. :)
We currently have the situation where a mail that will go over the
"Exceeded storage quota" limit, will be retried forever. It also seems
to be the case that all (even tiny mail) following will trigger the same
error. But I will deal only with the first case here.
On the test-vmx server, with no other email flowing, I can send it an
email, with a small gzip file, that tries to expand to 1G. This will
trigger the "Exceeded storage quota", but also get "stuck".
Logs look like, message arrives:
Jun 23 16:05:54 test-vmx01.unix amavis[19988]: [ID 702911 mail.info]
(19988-01)
ESMTP::10024 /var/amavis/tmp/amavis-20090623T160554-19988:
<f...@address.com>
-> <erint...@test.jorgen.jp> SIZE=2920 BODY=7BIT Received: from
mx.zero.jp ([12
7.0.0.1]) by localhost (vmx.zero.jp [127.0.0.1]) (amavisd-new, port
10024) with
ESMTP for <erint...@test.jorgen.jp>; Tue, 23 Jun 2009 16:05:54 +0900 (JST)
Jun 23 16:05:54 test-vmx01.unix amavis[19988]: [ID 702911 mail.info]
(19988-01)
Checking: OkXpOQBoZxIQ [210.172.146.149] <f...@address.com> ->
<erint...@test.jorgen.jp>
Jun 23 16:05:54 test-vmx01.unix amavis[19988]: [ID 702911 mail.info]
(19988-01) p003 1 Content-Type: multipart/mixed
Jun 23 16:05:54 test-vmx01.unix amavis[19988]: [ID 702911 mail.info]
(19988-01) p001 1/1 Content-Type: text/plain, size: 6 B, name:
Jun 23 16:05:54 test-vmx01.unix amavis[19988]: [ID 702911 mail.info]
(19988-01) p002 1/2 Content-Type: application/octet-stream, size: 910 B,
name: test.tbz
Testing starts:
Jun 23 16:05:58 test-vmx01.unix amavis[19988]: [ID 702911 mail.warning]
(19988-01) (!)Exceeded storage quota 1460000 bytes by run_command_copy;
last chunk 15360 bytes
Jun 23 16:05:58 localhost amavis[19988]: [ID 702911 mail.warning]
(19988-01) (!) Exceeded storage quota 1460000 bytes by run_command_copy;
last chunk 15360 bytes
Jun 23 16:05:58 test-vmx01.unix amavis[19988]: [ID 702911 mail.warning]
(19988-01) (!)killing process [27230] running /usr/bin/bzip2 (reason:
Exceeded storage quota 1460000 bytes by run_command_copy; last chunk
15360 bytes)
Jun 23 16:05:58 localhost amavis[19988]: [ID 702911 mail.warning]
(19988-01) (!)killing process [27230] running /usr/bin/bzip2 (reason:
Exceeded storage quota 1460000 bytes by run_command_copy; last chunk
15360 bytes)
Jun 23 16:05:58 test-vmx01.unix amavis[19988]: [ID 702911 mail.warning]
(19988-01) (!)do_uncompress: Exceeded storage quota 1460000 bytes by
run_command_copy; last chunk 15360 bytes
[repeat a lot]
I stopped amavisd after a while, but for example:
# gzcat maillog.20090623.gz|grep 'amavis\[19988\]' |grep 'Exceeded
storage quota' | wc -l
40344
Now, digging into the code.. I don't have clear view of how it actually
works, but at a guess:
"sub decompose_part" has an "eval" block, which calls
[1] "$sts = &$code($part,$tempdir,@args);"
this ends up in "do_uncompress" function. This also has an "eval" block
to execute
[2] "run_command". This will call "die(Exceeded storage quota)".
The "or do" part of [2] will catch that exception, and set "$eval_stat"
to "Exceeded storage quota". We will eventually return $retval, which is
now "0". I have confirmed this with oodles of do_log() calls.
Now, back in [1]. Since "die" only triggers the inner-most "eval"
(checked with perl -e command-line), the "eval" at [1] will not
break-out into the "or do" section. But rather set "$sts = 0".
The "eval" at [1] ends with "1;" so it will then complete as "true".
This means it skips the test..
[code]
} or do {
$eval_stat = $@ ne '' ? $@ : "errno=$!"; chomp $eval_stat;
if ($eval_stat =~ /^Exceeded storage quota/ ||
[/code]
..entirely.
Am I right in my reasoning? If I change "do_uncompress" to use
"die($eval_stat)" the "or do" clause is executed, and the match to
/Exceeded storage quota/ works. But this would mean a change in every
decode function defined.
Or instead, if I change "1;" to "$sts;" the eval will evaluate to
"false" when "do_uncompress" returns 0, but unfortunately, the outer
"eval" block has lost the "$@" string at this point, and does not work
correctly.
I have compared these functions against 2.6.3 but I see no obvious
fixes. I find it hard to believe it is broken for everyone, so it must
be something we do here.
Please hope us!
Lund
--
Jorgen Lundman | <lund...@lundman.net>
Unix Administrator | +81 (0)3 -5456-2687 ext 1017 (work)
Shibuya-ku, Tokyo | +81 (0)90-5578-8500 (cell)
Japan | +81 (0)3 -3375-1767 (home)
------------------------------------------------------------------------------
_______________________________________________
AMaViS-user mailing list
AMaViS-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/amavis-user
AMaViS-FAQ:http://www.amavis.org/amavis-faq.php3
AMaViS-HowTos:http://www.amavis.org/howto/
