Bug 88246
| 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: | |||||
| Severity: | medium | Docs Contact: | |||||
| Priority: | medium | ||||||
| Version: | 9 | CC: | starback, tmus, wirth, wtogami | ||||
| Target Milestone: | --- | ||||||
| Target Release: | --- | ||||||
| Hardware: | athlon | ||||||
| OS: | Linux | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2006-02-21 18:52:33 UTC | Type: | --- | ||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Embargoed: | |||||||
| Attachments: |
|
||||||
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! 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
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! spamassassin in rh9 definitly looses mails in the way described before at our site, too, there should really be done something against this. *** This bug has been marked as a duplicate of 86029 *** Changed to 'CLOSED' state since 'RESOLVED' has been deprecated. |
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.