Bug 3667 - spamd dies (prerelease version - 3.0.0-pre3), Debian stable
Summary: spamd dies (prerelease version - 3.0.0-pre3), Debian stable
Status: RESOLVED DUPLICATE of bug 3625
Alias: None
Product: Spamassassin
Classification: Unclassified
Component: spamc/spamd (show other bugs)
Version: unspecified
Hardware: PC Linux
: P4 major
Target Milestone: 3.0.1
Assignee: SpamAssassin Developer Mailing List
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2004-08-04 14:07 UTC by will yardley
Modified: 2004-09-24 02:21 UTC (History)
0 users



Attachment Type Modified Status Actions Submitter/CLA Status
strace output text/plain None will yardley [NoCLA]
better strace output text/plain None will yardley [NoCLA]

Note You need to log in before you can comment on or make changes to this bug.
Description will yardley 2004-08-04 14:07:14 UTC
Spamd, running on a Debian (woody/stable) machine; SA version is 3.0.0-pre3.
Perl is v5.6.1, which should be supported with this SA release. Spamassassin
built (cleanly) from source.

Normally, when spamd is running, there is a master process with several child
processes:
root      2041     1 15 13:53 ?        00:00:00 /usr/local/bin/spamd -d
jason     2048  2041  4 13:53 ?        00:00:00 spamd child
root      2049  2041  0 13:53 ?        00:00:00 spamd child
root      2050  2041  0 13:53 ?        00:00:00 spamd child
root      2051  2041  0 13:53 ?        00:00:00 spamd child
root      2052  2041  0 13:53 ?        00:00:00 spamd child

We have seen several instances of spamd dying at (seemingly) random intervals.

When this happens, there is a master process, and then one child process which
keeps dying.

root     30172     1  0 Aug01 ?        00:03:46 /usr/local/bin/spamd -d
root     32122 30172  0 13:51 ?        00:00:00 /usr/local/bin/spamd -d

root     30172     1  0 Aug01 ?        00:03:47 /usr/local/bin/spamd -d
root      1140 30172  0 13:52 ?        00:00:00 /usr/local/bin/spamd -d

root     30172     1  0 Aug01 ?        00:03:47 /usr/local/bin/spamd -d
root      1275 30172  0 13:52 ?        00:00:00 /usr/local/bin/spamd -d

Running strace on the parent process shows this... I'll try to attach a longer
file of this to the bug report later.

rt_sigaction(SIGCHLD, {0x80933f0, [], SA_RESTART|0x4000000}, {0x80933f0, [],
SA_RESTART|0x4000000}, 8) = 0
wait4(-1, 0xbfffe818, 0, NULL)          = -1 ECHILD (No child processes)
rt_sigaction(SIGPIPE, {SIG_DFL}, {SIG_DFL}, 8) = 0
rt_sigaction(SIGPIPE, {0x80933f0, [], SA_RESTART|0x4000000}, {SIG_DFL}, 8) = 0
rt_sigprocmask(SIG_BLOCK, NULL, [CHLD], 8) = 0
send(4, "<22>spamd[30172]: server hit by "..., 49, 0) = -1 ENOTCONN (Transport
endpoint is not connected)
fork()                                  = 923
wait4(923, [WIFEXITED(s) && WEXITSTATUS(s) == 0], 0, NULL) = 923
rt_sigaction(SIGPIPE, {SIG_DFL}, {0x80933f0, [], SA_RESTART|0x4000000}, 8) = 0
sigreturn()                             = ? (mask now [])
--- SIGCHLD (Child exited) ---
Comment 1 will yardley 2004-08-04 14:10:54 UTC
Created attachment 2216 [details]
strace output

Here's some strace output from the master process when the children keep dying.
If it happens again, I'll try an "strace -f" to see what's happening with the
child processes.
Comment 2 will yardley 2004-08-05 10:27:17 UTC
Created attachment 2219 [details]
better strace output

This time I remembered to do strace -f (to show what was happening with the
child processes as they kept dying). Let me know if I can get any other useful
debugging information.
Comment 3 Daniel Quinlan 2004-08-27 17:35:58 UTC
bugs for 3.0.1 milestone
Comment 4 Justin Mason 2004-09-24 10:21:41 UTC
I'm 99.9% certain this is bug 3625, already fixed before 3.0.0 general release

*** This bug has been marked as a duplicate of 3625 ***