Bug 3507 - Dns::pyzor_lookup() needs handler for $SIG{CHLD}
Summary: Dns::pyzor_lookup() needs handler for $SIG{CHLD}
Status: RESOLVED WORKSFORME
Alias: None
Product: Spamassassin
Classification: Unclassified
Component: Libraries (show other bugs)
Version: 2.63
Hardware: Other Linux
: P3 major
Target Milestone: Undefined
Assignee: SpamAssassin Developer Mailing List
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2004-06-14 10:00 UTC by Jeff Moss
Modified: 2005-01-21 03:20 UTC (History)
0 users



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 Jeff Moss 2004-06-14 10:00:36 UTC
There's a problem when trying to use Pyzor with both SpamPD and Amavisd-lite. 
It's probably in Amavisd-new as well.  In Dns::pyzor_lookup()Pyzor is given the 
message to process.  When it's finished it exits and throws a $SIG{CHLD}. That 
signal is unhandled and causes the process to die.  Thus the message does not 
get delivered.

If you add a local handler to the "eval" block where Pyzor is opened it solves 
this problem.  This is what I chose to add.

local $SIG{CHLD} = sub { dbg ("Pyzor exited like it's supposed to"); };

This problem is probably also in Dns::dcc_lookup() but I have not tested it.

  Jeff Moss
Comment 1 Michael Parker 2005-01-21 11:58:22 UTC
Some work was done in this area for 3.0, can you check against a more recent
version and see if this is still a problem?
Comment 2 Justin Mason 2005-01-21 12:20:53 UTC
btw, the normal way to deal with this is for SIGCHLD to be set to 'DEFAULT' or
'IGNORE'.  by default, it's 'DEFAULT' (obviously).  those builtin signal
handlers do not exit the process when a SIGCHLD is received, as that's a normal
IPC signal and non-fatal by any means.

I'd suggest fixing the upstreams, but in the meantime I'll put something into
3.1.0 along the lines you've described (ie. a scoped signal handler for helper
apps).  as Michael says, pls check with 3.0.0 too.

marking WORKSFORME...