Jeremy, > I have two different modules that are dumping core and causing the > AMaViS child to close. One is Razor2 and the other is SAVI-Perl. > I've been running AMaViS (currently 2.5.2) on RHEL4 using these two > modules for many years without problems, but recently two emails each > triggered a separate problem, one on each of these modules. The > SAVI-Perl problem appears to be in libsavi, and is failing on the last > few versions of SAV, but is OK when using versions prior to that. > > While I'm trying to get the authors to address their problems, I'm > also a bit surprised at how AMaViS behaved - it just closed, no logs, > no more processing, no file clean-up. The end result was two problems > that were difficult to find, emails that were repeatedly retried with > no response code, and a steadily filling /var/spool/amavis directory. > > I wonder if these sorts of things could (should?) be wrapped in an > eval(), and an appropriate response given back to the sending MTA > process, and a useful log message displayed. Or perhaps there's a way > the master can detect such failures in its children? When I use > "scan.pl" (from the SAVI-Perl utils) and "razor" to scan the > respective emails, glibc spits out a helpful error message, but this > doesn't show in the mail logs when AMaViS encounters the problem, > unless run in debug mode.
Unfortunately these kinds of errors (like SIGSEGV, SIGBUS, SIGFPE, SIGILL) can not be trapped by using an eval. The error happens in a library, below the perl level, and as a result the process just crashes, and the results are as you describe. This is probably what happens in the Sophos library as linked with SAVI-Perl. The master process (using Net::Server module) just spawns another replacement child if one passes out. It does not otherwise participate in communication and does not know what is going on in child processes. I would very much recommend not to use SAVI-Perl, but go for the Sophie interface, which decouples Sophos SAVI library from amavisd process, so if it crashes for some reason, it would not bring down the amavisd process. Similar applies to clamd vs. Mail::ClamAV. Another bonus is that this reduces the memory footprint of amavisd process considerably. Don't know what could be happening with razor, which is mainly in perl, except for libraries like crypto stuff. It could also be a runaway regular expression, which could crash perl. amavisd-new-2.4.5 introduced a setting $sa_spawned (see release notes), which allows SpamAssassin and its underlying modules to run as a forked process, so if it crashes, its parent amavisd process survives and can conclude the protocol with MTA. The penalty is doubling the memory footprint (twice the number of processes), so it is not a cheap protection. > When I use "scan.pl" (from the SAVI-Perl utils) and "razor" to scan the > respective emails, glibc spits out a helpful error message, but this > doesn't show in the mail logs when AMaViS encounters the problem, > unless run in debug mode. Does the scan.pl / razor process survive after spitting out the message? What is its exit status? It it terminates due to one of the above mentioned signals, there isn't much perl can do about it. But if it exits normally (regardless of exit status), then there is hope and the exact cause should be investigated and handled. Mark ------------------------------------------------------------------------------ Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev _______________________________________________ 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/
