Noah Meyerhans wrote: > If bug 739373 was triggered on the first sa-update run, then > /var/lib/spamassassin/3.004000 would have been created but never > populated with rules. This could leave spamassassin in a situation > similar to the one you're in. It would have to affect the very first run > of sa-update, though, because if that succeeded, then subsequent runs > would simply leave behind rules from a previous run. > > What I don't understand is what ran sa-update. It isn't run by postinst > or any other processes that would run during a package upgrade. Is > there anything else on your system that could have triggered sa-update?
Cron will run /etc/cron.daily/spamassassin when the time comes. I had
that situation on my machine. I enabled CRON=1 and I see that Stefano
had also enabled CRON=1 too.
Additionally I normally add the sought.rules.yerp.org channel in
/etc/cron.daily/spamassassin. Since that channel was functioning I
definitely had a /var/lib/spamassassin/3.004000 directory with the
sought rules but without the updates_spamassassin_org rules.
And then as an additional error message my spamassasin was then
complaining about being unable to find templates. I never figured
that part out because it wasn't important to me because of the other
problem.
> If you delete /var/lib/spamassassin/3.004000, you should be able to
> update to 3.4.0. Can you confirm this? If that works, then I'd be
> interested in seeing if things stay stable following a manual run of
> sa-update:
For what it is worth I just now tried a couple of experiments. I
purged all. I installed the previous version 3.3.2-7. I upgraded to
the latest 3.4.0-1. All was okay for me. I ran the cron script
/etc/cron.daily/spamassassin to run sa-update. All was okay for me.
I purged all. I installed spamassassin. I hacked the
/etc/cron.daily/spamassassin to only load my other additional channel
and not load any updates. Ran it. All worked okay.
I purged all. I installed spamassassin. I hacked do_dns_query in
sa-update to produce a bogus result for just the serial number. I did
it by adding this line (truly a hack) to break that specific case.
my $text = $rr->UNIVERSAL::can('txtdata') ? $rr->txtdata : $rr->rdatastr;
+ $text .= "555" if defined $text && $text ne '' && $text =~ m/^15/;
+ printf("DEBUG: hacking txt data: %s\n",$text);
push(@result,$text) if defined $text && $text ne '';
At that point I was able to completely recreate the problem I had
experienced and that you have proposed that Stefano experienced too.
sa-update output:
channel: could not find working mirror, channel failed
And if I try to run spamassassin I get this output:
config: no rules were found! Do you need to run 'sa-update'? at
/usr/bin/spamassassin line 407.
To me it seems that you have the root cause of the problem figured
out. It occurs if the upstream serial number is incorrect and there
hasn't ever been a correct set of rules loaded previously. In that
case the following are created which sets up the problem.
/var/lib/spamassassin/3.004000
/var/lib/spamassassin/3.004000/updates_spamassassin_org
/var/lib/spamassassin/3.004000/updates_spamassassin_org/MIRRORED.BY
The sa-update script could avoid this problem if it were to figure out
the serial number and channel first and then make the above
MIRRORED.BY only afterward.
Best would be if spamassassin itself was able to understand that this
directory is not fully populated yet and ignore it until it is so that
it could avoid the "no rules" error itself. If there is a bug to be
pointed at I think that is the place to point.
Hope that helps.
Bob
signature.asc
Description: Digital signature
