Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 88246 - spamd produces defunct process when spamc is called
Summary: spamd produces defunct process when spamc is called
Status: CLOSED DUPLICATE of bug 86029
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: spamassassin
Version: 9
Hardware: athlon
OS: Linux
Target Milestone: ---
Assignee: Chip Turner
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 2003-04-08 05:15 UTC by Graydon Saunders
Modified: 2007-04-18 16:52 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2006-02-21 18:52:33 UTC

Attachments (Terms of Use)
test mail that triggers the problem (deleted)
2003-04-21 20:36 UTC, Thomas M Steenholdt
no flags Details

Description Graydon Saunders 2003-04-08 05:15:56 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (compatible; Konqueror/3.1; Linux)

Description of problem:
spamd is started via the initscript when the system boots; no complaints, and no defunct processes.

The first time a user account gets mail and spamc is called, a defunct spamd process is created, owned by the user who called spamc.

[root@grithr root]# ps -ef | grep defunct
graydon   1387  1368  0 22:22 ?        00:00:00 [spamd <defunct>]

The mail is processed correctly; the additional headers in the mail look like (for some non-spam mail)

X-Spam-Status: No, hits=0.0 required=5.0
X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp)

the procmail rule in the user .procmailrc file looks like:
| /usr/bin/spamc

Subsequent mail gets through ok, gets through spamassassin, gets the header markup, and the same original defunct process is still sitting there.

spamassassin-2.50-4.8.x produces the same errors.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. put a :0fw rule calling spamc in a user .procmailrc file
2. have that user get mail

Actual Results:  got the mail ok, but have a defunct spamd process -

Expected Results:  Should have got the mail without spamd creating a defunct process.

Additional info:

The self-same .procmailrc file worked fine in RH 8.0; the breakage occured sometime between Phoebe 2 and Phoebe 3.

Comment 1 Thomas M Steenholdt 2003-04-21 20:34:39 UTC
Here's my take on this one...

I first noticed this problem when my wife recieved a mail from her boss... After
that mail checking through ipop3d failed, complainting about invalid mailbox
format(the mailbox (/var/spool/mail/username) at this time is 1 byte in size
containing only a '0x0a' char).

Please notice that I do NOT get the affected mail, ever!
Checking my mail when the error has occurred (over ipop3d) results in an
error... That error only goes away after sending a new message(blank or
something) because that "repairs" my /var/spool/mail/username file.

I have not been able to track down the exact problem, but I produced a mail-file
that will trigger the error... Just run 'cat test_mail_bad |spamc' and a
following 'ps aux' will show the defunct process.

I have upgraded to SpamAssassin version 2.53 and cant seem to reproduce with the
same mails now.

Hope this is of help!

Comment 2 Thomas M Steenholdt 2003-04-21 20:36:38 UTC
Created attachment 91208 [details]
test mail that triggers the problem

This mail triggers the problem... 'cat test_mail_bad |spamc' and notice that no
output is produced and there is a defunct spamd process afterwards

Comment 3 Thomas M Steenholdt 2003-04-22 08:12:07 UTC
I think we can justify a higher prio on this one, since users can actually loose
mails as a result of this problem!
Could the bug potentially be exploited? If so, maybe an even higher
priority/severity may be required!

Comment 4 Helmut Wirth 2003-10-17 09:05:46 UTC
spamassassin in rh9 definitly looses mails in the way described before at
our site, too, there should really be done something against this.

Comment 5 Warren Togami 2004-02-29 06:22:10 UTC

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

Comment 6 Red Hat Bugzilla 2006-02-21 18:52:33 UTC
Changed to 'CLOSED' state since 'RESOLVED' has been deprecated.

Note You need to log in before you can comment on or make changes to this bug.