Bug 88246 - spamd produces defunct process when spamc is called
spamd produces defunct process when spamc is called
Status: CLOSED DUPLICATE of bug 86029
Product: Red Hat Linux
Classification: Retired
Component: spamassassin (Show other bugs)
9
athlon Linux
medium Severity medium
: ---
: ---
Assigned To: Chip Turner
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2003-04-08 01:15 EDT by Graydon Saunders
Modified: 2007-04-18 12:52 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-02-21 13:52:33 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
test mail that triggers the problem (769 bytes, text/plain)
2003-04-21 16:36 EDT, Thomas M Steenholdt
no flags Details

  None (edit)
Description Graydon Saunders 2003-04-08 01:15:56 EDT
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
        tests=none
        version=2.50
X-Spam-Level:
X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp)

the procmail rule in the user .procmailrc file looks like:
:0fw
| /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):
spamassassin-2.44-11.8.x

How reproducible:
Always

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

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 16:34:39 EDT
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 16:36:38 EDT
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 04:12:07 EDT
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!
Thanks!
Comment 4 Helmut Wirth 2003-10-17 05:05:46 EDT
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 01:22:10 EST

*** This bug has been marked as a duplicate of 86029 ***
Comment 6 Red Hat Bugzilla 2006-02-21 13:52:33 EST
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.