Bug 1689211
Summary: | Exim's greylist-tidy.sh daily cron reports an error when greylist.db is empty | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Dennis Flaherty <dennisf> |
Component: | exim | Assignee: | Jaroslav Škarvada <jskarvad> |
Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | medium | Docs Contact: | |
Priority: | unspecified | ||
Version: | 28 | CC: | bennie.joubert, dwmw2, jskarvad, tremble |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | All | ||
OS: | All | ||
Whiteboard: | |||
Fixed In Version: | exim-4.92-5.fc28 exim-4.92-5.fc29 exim-4.92-6.fc30 | Doc Type: | If docs needed, set a value |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2019-03-29 02:03:59 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: |
Description
Dennis Flaherty
2019-03-15 12:39:22 UTC
I had made the above fix locally but each new version of Exim clobbers my local fix. Thanks, it makes sense. exim-4.92-5.fc30 has been submitted as an update to Fedora 30. https://bodhi.fedoraproject.org/updates/FEDORA-2019-05194f6b09 exim-4.92-5.fc29 has been submitted as an update to Fedora 29. https://bodhi.fedoraproject.org/updates/FEDORA-2019-b46c6fd50c exim-4.92-5.fc28 has been submitted as an update to Fedora 28. https://bodhi.fedoraproject.org/updates/FEDORA-2019-037c4fac81 Thank you Jaroslav. Why would the file be empty? The RPM's %post script creates it with the appropriate contents. You'd have to deliberately go and corrupt it, surely? We don't normally make packages cope with someone who deliberately goes and corrupts their files. Not that I have any particular objection to the change, but I'm confused by it. My greylist.db was indeed empty. If a post script was supposed to create it with appropriate contents, I didn't see it. I don't normally corrupt my files and post to bugzilla. (In reply to Dennis Flaherty from comment #8) > My greylist.db was indeed empty. If a post script was supposed to create it > with appropriate contents, I didn't see it. > > I don't normally corrupt my files and post to bugzilla. The following is in the SPEC: %post greylist if [ ! -r %{_var}/spool/exim/db/greylist.db ]; then sqlite3 %{_var}/spool/exim/db/greylist.db < %{_sysconfdir}/exim/mk-greylist-db.sql chown exim.exim %{_var}/spool/exim/db/greylist.db chmod 0660 %{_var}/spool/exim/db/greylist.db fi so it should be initialized and your installation is very probably somehow corrupted. The question is do we want the cron script to: a) silently tolerate the corrupt file and not work or b) report error After re-thinking about it, I think the b) is better way how to deal with it, so I am OK to revert the change. I tried to install exim-greylist on my test system and it was correctly initialized as expected: sqlite3 /var/spool/exim/db/greylist.db .dump PRAGMA foreign_keys=OFF; BEGIN TRANSACTION; CREATE TABLE resenders ( host TEXT, helo TEXT, time INTEGER, PRIMARY KEY (host, helo) ); CREATE TABLE greylist ( id TEXT PRIMARY KEY, expire INTEGER, host TEXT, helo TEXT ); COMMIT; I've removed exim-greylist on my system, then reinstalled it. I now see a non-zero greylist.db. Note that the Exim snippets won't work when the DB is empty either. Making the cron job resilient to an empty file is all very well (and I don't really object to it), but anyone who is *using* this package won't cope with an empty file. And it doesn't provide any benefit at all to anyone who isn't using it. (In reply to David Woodhouse from comment #12) > Note that the Exim snippets won't work when the DB is empty either. Making > the cron job resilient to an empty file is all very well (and I don't really > object to it), but anyone who is *using* this package won't cope with an > empty file. And it doesn't provide any benefit at all to anyone who isn't > using it. OK, thanks for info, let's keep the change. exim-4.92-5.fc29 has been pushed to the Fedora 29 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2019-b46c6fd50c exim-4.92-5.fc28 has been pushed to the Fedora 28 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2019-037c4fac81 exim-4.92-6.fc30 has been submitted as an update to Fedora 30. https://bodhi.fedoraproject.org/updates/FEDORA-2019-7b741dcaa4 exim-4.92-6.fc30 has been pushed to the Fedora 30 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2019-7b741dcaa4 exim-4.92-5.fc28 has been pushed to the Fedora 28 stable repository. If problems still persist, please make note of it in this bug report. exim-4.92-5.fc29 has been pushed to the Fedora 29 stable repository. If problems still persist, please make note of it in this bug report. exim-4.92-6.fc30 has been pushed to the Fedora 30 stable repository. If problems still persist, please make note of it in this bug report. |