|Summary:||spamd produces defunct process when spamc is called|
|Product:||[Retired] Red Hat Linux||Reporter:||Graydon Saunders <oak>|
|Component:||spamassassin||Assignee:||Chip Turner <cturner>|
|Status:||CLOSED DUPLICATE||QA Contact:|
|Version:||9||CC:||starback, tmus, wirth, wtogami|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2006-02-21 18:52:33 UTC||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
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 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 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! Thanks!
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.