1

I have a mailfilter system based on that described at: http://www200.pair.com/mecham/spam/ (Debian Lenny, postfix / amavisd-new / spamassassin / policy-weightd, etc.)

This system has been running flawless for us for the past few years (on Etch first, then re-built on Lenny after it was released)

Then in the past week, the amavisd-new process has been locking up in such a way that:

  • there are still amavid processes running - all marked with "(accept)" as opposed to "(avail)"
  • I can still make a telnet connection to the amavis port, but it sits there connected with no response
  • running amavisd-nanny locks up my ssh session and I have to abort and start a new ssh session.
  • Curious log entries "amavis[25474]: (25474-20) Requesting process rundown after 20 tasks" seem to occur before a process gets frozen in the "(accept)" state.
  • This has been happening on both of our (nearly identical) mailfilters, starting at the same time (about the time of the below mentioned libaprutil1 upgrade)

I haven't been able to discover much on my own, and am wondering if anyone here is facing the same thing?

Can anybody point me in the right direction on this?

4
  • Can you set some debugging mode to know what is going behind the scenes?
    – cstamas
    Jun 20, 2009 at 13:59
  • The log entries regarding "rundown" appear to be the culprits - but I don't know what rundown means
    – Brent
    Jun 20, 2009 at 16:27
  • Can you please provide the version numbers for your Amavis install, perl install, and the Net::Server revision level? Jun 23, 2009 at 18:58
  • Sure - amavisd-new-2.6.2, perl-5.10.0, libnet-server-perl-0.97.1
    – Brent
    Jun 23, 2009 at 21:28

2 Answers 2

0

The "newer" versions of amavisd-new will wedge over time. I encounter this about every 5-6 months. I haven't traced the issue directly but it appears to be an issue with the perl installation that comes with RHEL/CentOS (which is what I am running).

I can tell you that you'll want to adjust the child lifetime down quite a bit, say 10-30 runs each, as this seems to mitigate the worst of it. It also seems that spam storms can cause the process a bit of grief and under heavy load, causes some children to die.

I wish I had more I could tell you, but that's what I have. Oh, and are you updating modules out of CPAN? On Debian I believe this works correctly, but on RHEL/CentOS this has been documented for some time to cause all kinds of grief. If all else fails, rev the newest version of spamassassin in CPAN, which in the past has also mitigated some issues.

UPDATE:

The official page mentions several issues, including some incompatibilities between Net::Server and newer versions. As I don't have any version numbers to reference, I suggest you (a) get the version of amavis you're using from rpm -q (b) use CPAN to determine what version of Net::Server you're running.

3
  • Thank you, I will try adjusting the child lifetime and see if it helps. I also read somewhere about a related issue that increasing sa_timeout could help.
    – Brent
    Jun 22, 2009 at 13:17
  • Thanks alot - I have added the version numbers in a comment to the original question, but will check out the link above.
    – Brent
    Jun 23, 2009 at 21:35
  • Looks like my versions are considerably newer than those mentioned in your link.
    – Brent
    Jun 23, 2009 at 21:38
0

I think I found the solution:

Essentially, the pyzor server IP addresses has changed. This can be confirmed by running pyzor ping and su amavis -c 'pyzor ping' and getting timeouts for each.

This can be resolved this by running pyzor discover; su amavis -c 'pyzor discover', and setting up a regular cron job to run this command (in case it changes again in the future)

Ever since I made this change, amavisd has stopped "jamming" on me.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .