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
