Also check that the actual spamassassin config directory is
/etc/spamassassin and that there is a symlink at /etc/mail/spamassassin
-> /etc/spamassassin
If not, create it with ln -s /etc/spamassassin /etc/mail/spamassassin
On 2019/02/12 08:14, Ken Wright wrote:
On 2/11/19 11:42 PM, Bill Cole wrote:
On 11 Feb 2019, at 21:40, Ken Wright wrote:
On 2/11/19 9:33 PM, Bill Cole wrote:
On 11 Feb 2019, at 20:24, Ken Wright wrote:
it does say it's loading the Mail::SpamAssassin::Plugin::Check module
This is evidence that one or more of the following is true about spamd:
1. It is using a different SpamAssassin config than you use from the
command line
2. It is using a different perl executable than you use from the
command line (e.g. perlbrew)
3. It is using a different perl library path than you use from the
command line (e.g. local::lib)
I'm still kind of a n00b, so... how can I tell which? I have no GUI on
the server, so everything is from the command line.
OK, so you'd probably know if you had installed perlbrew or otherwise
rigged up a way that you could accidentally run different perl
executables from systemd and from the command line. So #2 is
*probably* eliminated. Simplest solid check: look at the first line
(starting with '#!') of the spamassassin script and of spamd (which is
also a Perl script) and confirm that they are identical and DO NOT use
/bin/env or /usr/bin/env to find perl. If they are not identical, then
you probably have issues #1 and #2 together. If they use the env
trick, they may be finding different perl executables.
I haven't installed perlbrew or anything like that, as far as I know.
Where would I find the two scripts you mentioned?
#1 is only likely if you have installed SpamAssassin in multiple ways,
e.g. from the distribution's package for it and from source or using
CPAN. If you have stuck strictly to using the standard packages for SA
and Perl and the various Perl modules that SA depends on, you would
have a hard time creating this issue without trying very hard. If you
have tried installing SA and/or its dependencies "by hand" or using
CPAN instead of using the prebuilt packages, clean up that mess and
reinstall from packages. A bespoke artisanal installation is
inappropriate for someone who claims to be "kind of a n00b."
I installed SA from the Ubunto repositories only. I have, however,
installed a few modules (such as Geo::IP) from CPAN, after starting with
the debug flag indicated there were a few uninstalled modules (such as
Geo::IP). Repeating the debug start showed all those modules installed,
so I don't think that's the issue.
#3 is actually not unlikely. I don't know if Ubuntu 18 does it, but I
know that the EL7 family of distributions have instituted local::lib
as a default, which means that an interactive login gets $PERL5LIB set
to look in ~/perl5/ for installed modules. A service started out of
systemd won't have that. If you've somehow managed to install SA under
~/perl5/ then spamd won't find it. You can just run "echo $PERL5LIB"
to see if your login has that set.
I ran "echo $PERL5LIB" with and without sudo. In both cases all I got
was a new line.
One way to debug this would be to add "-D all" to the OPTIONS
parameter in /etc/default/spamassassin and try starting it. This
should spew a lot of debug output into the log, which you can compare
to what you got from running spamassassin from the command line with
'-D' to look for discrepancies in where it is looking for config files
and libraries.
I notice the path shown for SA doesn't include /etc/spamassassin, which
is where all the .pre files are. Is this it? Am I just not finding the
necessary .pre files?
Ken
--
Kind Regards,
Evan Booyens
Linux Systems Engineer
Hetzner (Pty) Ltd
SA Contact Centre: 0861 0861 08
International: +27 21 970 2000
Website: hetzner.co.za <http://www.hetzner.co.za>
Disclaimer: hetzner.co.za/email-disclaimer
<http://www.hetzner.co.za/email-disclaimer>
