|
SA Bugzilla – Full Text Bug Listing |
Summary: | [review] spamd keeps dead kids in state 'K', causing child hash to fill up | ||
---|---|---|---|
Product: | Spamassassin | Reporter: | Kris Deugau <kdeugau> |
Component: | spamc/spamd | Assignee: | SpamAssassin Developer Mailing List <dev> |
Status: | RESOLVED FIXED | ||
Severity: | normal | ||
Priority: | P4 | ||
Version: | 3.2.3 | ||
Target Milestone: | 3.2.4 | ||
Hardware: | PC | ||
OS: | Linux | ||
Whiteboard: | ready to commit for 3.2 | ||
Attachments: |
Quick hack to clean up ghost K-state children
minor tweak |
Description
Kris Deugau
2007-10-02 08:11:42 UTC
Created attachment 4142 [details]
Quick hack to clean up ghost K-state children
The attached patch seems to be working to eliminate the ghost K-state children;
I've patched the four production machines that were showing the problem and
all four are stable. One has been running for ~3 hours, where it would have
accumulated ~5-8 (possibly more) ghost children without the patch during that
time.
The patch as-is includes some debug "logging", and could probably be vastly
improved.
Kris, if that patch works OK, it looks good to me. Could you monitor it for a few more days and let me know if it's still working, by the end of that? If it is, I'll add the patch to SVN and 3.2.x. (In reply to comment #2) > Kris, if that patch works OK, it looks good to me. Could you monitor it for a > few more days and let me know if it's still working, by the end of that? If > it is, I'll add the patch to SVN and 3.2.x. ACK OK. FWIW, it's been stable well beyond the point of "spamd ran out of child slots" already, but I'll still watch it for another day or so to make sure it doesn't eat the servers or stomp all over something else. On one machine I'm seeing the "prefork: debug:" notes every ~3 minutes. O_o I honestly can't tell whether this is just papering over the "real" problem somewhere else, or doing exactly what I intended and providing a little extra cleanup where it's needed. (In reply to comment #3) > FWIW, it's been stable well beyond the point of "spamd ran out of child slots" > already, but I'll still watch it for another day or so to make sure it doesn't > eat the servers or stomp all over something else. Still stable on all four machines that were showing the problem. None have needed spamd restarted since I applied the patch; unpatched spamd would run out of child slots within 6-8 hours at most. No apparent problems with any other services (not that there's much else beyond SA). No zombie children left hanging around where there shouldn't be. Created attachment 4143 [details]
minor tweak
Kris, could you try this version of the patch? it removes a redundant
delete_socket_for_child() call and quiets down the debugging, but otherwise
should be exactly the same.
(In reply to comment #5) > Created an attachment (id=4143) [edit] > minor tweak > > Kris, could you try this version of the patch? it removes a redundant > delete_socket_for_child() call and quiets down the debugging, but otherwise > should be exactly the same. Seems to be working; one system is stable for 3 hours so far. Unpatched, ghost children usually show up within 15-20 minutes. ok, applied to 3.3.0: : jm 189...; svn commit -m "bug 5665: spamd may fail to notice that a child has completed exiting, and keeps it in the child list in state 'K', eventually filling up the child list with 'ghost' children. fix" lib/Mail/SpamAssassin/SpamdForkScaling.pm Sending lib/Mail/SpamAssassin/SpamdForkScaling.pm Transmitting file data . Committed revision 582610. committers, votes please... From my memory of how SpamdForkScaling works it looks safe, so +1. +1 fix checked in for 3.2.x: r604706 |