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.