Bug 4573 - Changing the handler for SIGCHILD breaks Mimedefang
Summary: Changing the handler for SIGCHILD breaks Mimedefang
Status: NEW
Alias: None
Product: Spamassassin
Classification: Unclassified
Component: spamassassin (show other bugs)
Version: 3.1.0
Hardware: All All
: P3 normal
Target Milestone: Undefined
Assignee: SpamAssassin Developer Mailing List
: 4556 (view as bug list)
Depends on:
Reported: 2005-09-07 19:24 UTC by Loren Wilton
Modified: 2005-09-09 23:38 UTC (History)
1 user (show)

Attachment Type Modified Status Actions Submitter/CLA Status

Note You need to log in before you can comment on or make changes to this bug.
Description Loren Wilton 2005-09-07 19:24:42 UTC
A number of users of MD seem to be having problems with mail scanning, 
apparently seeing _alarm_ interrupts in their log.  Along with each occurance 
of a log record they get an unscanned spam passed through.

The following item was posted to the users list by John Rudd, but considerable 
encouragement has not resulted in him posting it here where it can be looked 
at, so I'm posting the contents of his original posting.

It is obvious that this problem, which seemingly showed up on RC1, is related 
to the recent change that changes the SIGCHILD handler to try to avoid nasty 
messages from (I think it was) spamd.

Subject: Problems with SpamAssassin 3.1 RC1and MIMEDefang

This is a problem that some mimedefang people are experiencing with SA 
3.1 rc1.

(mimedefang slave processes are becoming un-killable due to a 
mis-feature in SA 3.1 which messes with SIGCHLD)

Begin forwarded message:

> From: "David F. Skoll" <dfs@roaringpenguin.com>
> Date: August 27, 2005 6:01:28 PM PDT
> To: mimedefang@lists.roaringpenguin.com
> Subject: Re: [Mimedefang] Problems with SpamAssassin 3.1 RC1and 
> MIMEDefang
> Martin Blapp wrote:
>> Please download SA3.1 Pre 1 and try yourself.
> I downloaded it, and didn't have to try anything; the problem was 
> obvious
> after I read the SA 3.1 code.
> It's a bug in SA 3.1.
> Look at the file "Dns.pm", in the routine enter_helper_run_mode.
> We see this code:
>   # enforce SIGCHLD as DEFAULT; IGNORE causes spurious kernel warnings
>   # on Red Hat NPTL kernels (bug 1536), and some users of the
>   # Mail::SpamAssassin modules set SIGCHLD to be a fatal signal
>   # for some reason! (bug 3507)
>   $self->{old_sigchld_handler} = $SIG{CHLD};
> There's a leave_helper_run_mode that resets the SIGCHLD handler to its
> old value.
> HOWEVER: If the slave dies sometime between enter_helper_run_mode and
> leave_helper_run_mode, the multiplexor never gets a SIGCHLD signal.
> I don't know why the SA developers are even monkeying with the SIGCHLD 
> handler
> in the Perl module; you'd have to ask them.  It seems like a bad idea
> to me.
> I think I have a workaround; I'll release a beta soon.
> In the meantime, I believe that turning off the embedded interpreter 
> will
> make it work properly.
> Regards,
> David.
Comment 1 Dianne Skoll 2005-09-08 04:12:39 UTC
MIMEDefang 2.53 has a workaround for this.
Comment 2 Nels Lindquist 2005-09-08 13:10:16 UTC
*** Bug 4556 has been marked as a duplicate of this bug. ***
Comment 3 Justin Mason 2005-09-08 18:04:50 UTC
1. first off, if there's a better setting for SIGCHLD for MIMEDefang, it'd be
handy to know.  Perhaps we should offer an API for MIMEDefang to register with,
and it'd be called when entering/leaving helper-app run mode?

Unfortunately we do need to pull special SIGCHLD tricks due to bug 1536 and bug
3507, as the comment notes.

2. however, there is another option -- use a DESTROY hook on an object to
perform the leave_helper_run_mode() logic.  that way even if the code is
signalled and interrupted, that code will always be run (once the object goes
out of scope) -- and in this case the old $SIG{CHLD} will always be restored

Would that help?
Comment 4 Justin Mason 2005-09-08 18:07:43 UTC

3. another option, really a subset of 1. -- simply add a flag to the Mail::SA
ctor indicating that the caller can deal with SIGCHLDs themselves just fine, and
enter/leave_helper_run_mode() should never mess with them.  MIMEDefang (and
others possibly) can then pass that flag.
Comment 5 Dianne Skoll 2005-09-10 07:38:55 UTC
(In reply to comment #3)
> 1. first off, if there's a better setting for SIGCHLD for MIMEDefang, it'd be
> handy to know.

The issue is that MIMEDefang can use an embedded Perl interpreter, and it's a
bit weird.  In the parent process, we use Mail::SpamAssassin and do some
initialization.  We then fork and the child processes actually call into
SpamAssassin to do work.  The problem appears to be that the initialization code
was resetting SIGCHLD and not setting it back, and so the parent process lost
track of its children.

The fix in MIMEDefang was to forcibly reset SIGCHLD after the Perl
initialization code had run, and that fixed it.  So it's no longer an issue for me.