[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

[Mark.Martinec@ijs.si: Re: [AMaViS-user] Hang of amavis-postfix]



Hello,

Mark, the upstream maintainer of amavis discourages use of current
versions of amavisd on "production machines" with perl 5.8 due to
differences in signal handling.

What should I do in this situation?

Options I can think of:

A pretend problem doesn't exist.
B add debconf warning or warning to README.Debian.
C remove package from unstable.

At least until Mark has a new version which will fix this
problem (assuming this is possible with perl 5.8; I am a bit
doubtful myself, but I haven't looked at perl 5.8).

What should I do?
-- 
Brian May <bam@debian.org>
--- Begin Message ---
| i had a similar problem using a combination *other* than 
| what mark says causes it, and specifically *not* content related.
| i'm not using anti-virus on this machine, but am doing running spam-assassin.
| once i killed the process, the mail would be requeued, and properly
| spam-graded.
| my "solution" (just a loathsome hack) is to run via crontab the 
| following script, amaviswatchkill):

Ok.


As a general consideration:

- if the problem is content related, thus repeatable,
  the best contribution to the community would be to
  track down the SA or Perl problem, and complain to the
  appropriate forum;

- with Perl 5.8.0 the signal handling has changed. A signal (e.g. alarm)
  only gets noticed in the 'clean' spots between Perl statements.
  This makes the alarm-based timeouts used by amavisd-new useless
  if Perl itself goes in a loop, e.g. within a pattern matching.
  What was once a 'timed out in ..., retry' situation with Perl 5.6.x,
  is now a denial-of-service situation;

- summary: don't run Perl 5.8.0 on a production machine
  if using SpamAssassin.


Mark

--- End Message ---

Reply to: