http://issues.apache.org/SpamAssassin/show_bug.cgi?id=4304
------- Additional Comments From [EMAIL PROTECTED] 2006-10-04 04:36 -------
'I can sort of repro the condition by inserting an exit(0); right before the
server-side of the fork returns from spawn().'
ah, yes, well that would be expected -- the children won't exit if they're not
told to, and exit(0) at that point would never tell them to. I don't think
that's a valid test case, unfortunately, as a result.
I've written a test case here, and by adding a "sleep(5);" directly after
'$spamtest->call_plugins("spamd_child_init");', I can reproduce the problem you
describe in comment 9. It goes like this:
- external process starts up spamd
- spamd blocks SIGINT
- spamd forks off children
- external process kills spamd parent, it dies nearly immediately
- spamd children runs 'sleep(5)'
- external process starts new spamd parent (after short pause)
- new spamd parent chokes saying socket already in use
- spamd children finish loading up, unblock SIGINT, receive SIGINT and then die
that's pretty much what you describe... so that definitely *is* a bug.
If I move setup_child_sig_handlers() and sigprocmask( POSIX::SIG_UNBLOCK(),
$sigset ) to between "## CHILD" and
"$spamtest->call_plugins("spamd_child_init");", as the patch does, this is
fixed.
Since it's a confirmed bug, I've checked that into SVN trunk as r452849, anyway
;)
Some other things, though:
You say 'spamd children continue loading things up (this takes a while in our
environment)'. What is this exactly?
You note:
'if I know the parent is dead but I don't see a
"spamd: server killed by SIG$sig, shutting down" line in the logfile'
This can happen if a non-TERM or non-INT signal was sent -- like a SIGKILL
or (worse) a SIGBUS or SIGSEGV error. are you sure it's not something
more serious causing that?
also;
'Thinking of it that way I can't quite understand why the signal blocking is
there at all. I have a version of spamd here that removes all of it. Doesn't
help this particular case but may be worth putting in anyway?'
definitely not a good idea ;) the signal handling there is used
to avoid a known deadlock at fork() time -- the child pids cannot
use the same signal handler as the parent until after fork(), so the
only safe option is to keep signals masked until after fork and the
new child sig handlers are installed. This is pretty vital. The
bug however was that the masking was being kept on far too long.
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
