Bug 874397
| Summary: | Mailman makes multiple mails having the same sequence number, namely makes duplicated sequence number in subject prefix. | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | Red Hat Enterprise Linux 5 | Reporter: | Yoshifumi Kinoshita <ykinoshi> | ||||||
| Component: | mailman | Assignee: | Jan Kaluža <jkaluza> | ||||||
| Status: | CLOSED WONTFIX | QA Contact: | qe-baseos-daemons | ||||||
| Severity: | unspecified | Docs Contact: | |||||||
| Priority: | unspecified | ||||||||
| Version: | 5.8 | CC: | wburrows | ||||||
| Target Milestone: | rc | ||||||||
| Target Release: | --- | ||||||||
| Hardware: | Unspecified | ||||||||
| OS: | Unspecified | ||||||||
| Whiteboard: | |||||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||||
| Doc Text: | Story Points: | --- | |||||||
| Clone Of: | |||||||||
| : | 875149 (view as bug list) | Environment: | |||||||
| Last Closed: | 2013-03-11 09:01:47 UTC | Type: | Bug | ||||||
| Regression: | --- | Mount Type: | --- | ||||||
| Documentation: | --- | CRM: | |||||||
| Verified Versions: | Category: | --- | |||||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||||
| Embargoed: | |||||||||
| Bug Depends On: | |||||||||
| Bug Blocks: | 875149 | ||||||||
| Attachments: |
|
||||||||
Because of those 2 situation described in previous comment, the incremented sequence number is lost and some old is used twice for next emails. Created attachment 643977 [details]
upstream version of proposed patch
I am sorry, but it is now too late in the RHEL-5 release cycle. RHEL-5.10 (the next RHEL-5 minor release) is going to be the first production phase 2 [1] release of RHEL-5. Since phase 2 we'll be addressing only security and critical issues. There is clone of this bug for RHEL-6 (Bug 875149) and this issue will be fixed only in RHEL6. If you think this should be fixed in RHEL-5, try to escalate your issue. [1] https://access.redhat.com/support/policy/updates/errata/ |
Created attachment 641569 [details] proposed patch If two qrunner processes access list configuration file in the same second, second qrunner proces does not reload the configuration file, because it thinks that it has not changed. The decision is made according to modification time, which is always in seconds (not in miliseconds) in RHEL5. Second problem is that during the GENERAL_PIPELINE, in some cases the lock file is unlocked and next mlist.Save() fails. The patch checks for this case and try to Lock() the mailing list again.