amavis-user September 2010 archive
Main Archive Page > Month Archives  > amavis-user archives
amavis-user: Re: [AMaViS-user] Amavis Crashes on Solaris x86

Re: [AMaViS-user] Amavis Crashes on Solaris x86

From: Mark Martinec <Mark.Martinec+amavis_at_nospam>
Date: Tue Sep 14 2010 - 16:31:33 GMT


> I've changed sa_debug to 1 and log_level to 5. This are the last log
> entries before the crash: [...]
> If needed, I could also provide the complete log file.

Thanks. The 03003-02 is the only one whose log starts early enough
to be informative. A grep on '03003-02' yields the most informative part:

Sep 13 22:04:22 ocswchzrhse01 amavis[3003]: [ID 702911] (03003-02)
  SA dbg: rules: running full_eval tests; score so far=14.435
Sep 13 22:04:22 ocswchzrhse01 amavis[3003]: [ID 702911] (03003-02)
  SA dbg: dns: entering helper-app run mode
Sep 13 22:04:23 ocswchzrhse01 amavis[3003]: [ID 702911 mail.debug] (03003-02)
  SpamControl: rundown_child on SpamAssassin done
Sep 13 22:04:23 ocswchzrhse01 amavis[3003]: [ID 702911 mail.debug] (03003-02)
  child_finish_hook: invoking DESTROY methods

> >> It seems the crash occurs while attempting to extend the
> >> process' virtual memory (the _morecore). Could it be that the
> >> swap space is too small? Or perhaps we are dealing with a
> >> runaway regular expression.
> >
> > Oh, this might be the Actually, this might be an issue with VmWare's
> > memory balloon driver. I'll try first to disable the vmmemctl driver.
> It seems that it's not an issue with vmmemctl (VmWare Balloon Driver).
> I've started the OS without the vmmemctl driver and there is
> definitively no memory issue.

We see the 'dns: entering helper-app run mode', but before SpamAssassin
reaches a 'dns: leaving helper-app run mode' something sinister strikes
and the code aborts, only to be caught by an 'eval' condition handler
at a very high level (in Net::Server).

Between the 'entering' and 'leaving' there is typically one of the
external programs executed as invoked by a SA plugin, such as:
pyzor, dcc, crm114, or Razor2. The first three would create a pipe
and fork/exec an external process. The Razor2 is different, it just
executes perl code within the context of the same process.

The dcc and pyzor would log something like 'dcc: dccproc is available:'
just before 'entering helper-app run mode', which leaves Razor2
as a prime suspect in your case.

It has been reported before that razor agents can cause a crash.
For starters, make sure you have the most recent (yet rather old)
version of Razor2 perl module.


Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing.
AMaViS-user mailing list
 Please visit regularly
 For administrativa requests please send email to rainer at openantivirus dot org