https://bz.apache.org/SpamAssassin/show_bug.cgi?id=8306
Bug ID: 8306
Summary: spamassassin/spamd can't find rules if initial
sa-update run fails
Product: Spamassassin
Version: 4.0.1
Hardware: PC
OS: Linux
Status: NEW
Severity: minor
Priority: P2
Component: spamassassin
Assignee: dev@spamassassin.apache.org
Reporter: fr...@morgul.net
Target Milestone: Undefined
This was originally reported to Debian ages ago in
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=739489. I've confirmed that
the behavior is still present.
If spamassassin is installed entirely through tarballs or distro packages
(including rules in the DEF_RULES_DIR), then it will use the installed rules as
expected. If sa-update runs at a later time but is unable to download rules for
some reason, then spamassassin will no longer start successfully. It will try
using rules from the LOCAL_STATE_DIR, which exists because sa-update created
it, but it will fail because there aren't actually any rules there.
This could happen due to misconfiguration of the local system (e.g. the network
being offline) or transient upstream issues, e.g. DNS resolution problems.
Easiest way to reproduce this:
1. Download and install the Mail-SpamAssassin-4.0.1.tar.gz and
Mail-SpamAssassin-rules-4.0.1.r1916528.tgz files from the spamassassin web site
2. Verify with `spamassassin -D --lint` that the installation is successful and
that SA is using /usr/local/share/spamassassin for rules
3. Disconnect the system from the network
4. Run sa-update. This will fail because the update servers are unreachable
5. Run `spamassassin -D --lint`. This will now fail with "config: no rules
were found! Do you need to run 'sa-update'?"
A couple of possible solutions come to mind. sa-update could (and probably
should) not create any final paths until it has successfully retrieved content.
Or spamassassin/spamd could fall back from the LOCAL_STATE_DIR to the
DEF_RULES_DIR if attempts to read rules from the former fail.
--
You are receiving this mail because:
You are the assignee for the bug.
