On 2/12/19 9:53 AM, Bill Cole wrote: > On 12 Feb 2019, at 1: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? > > Running 'which spamassassin' will give you the full path to the > spamassassin script that you are running. The full path to the spamd > being run by systemd should be /usr/sbin/spamd if the Debian package > hasn't been mangled, and you can see for sure in the "ExecStart " line > in the unit file for SpamAssassin: > /etc/systemd/system/spamassassin.service (if that exists) or > /lib/systemd/systemd/spamassassin.service > Okay, I checked. Both Spamassassin and spamd start with #!/usr/bin/perl -T -w. No env variables. > >>> #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. > > Maybe we need to see the whole output from a debug start attempt and > from a command-line interactive 'spamassassin --lint -D' run. > > [...] >>> 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? > > Possible, but unlikely since running the spamassassin script doesn't > have the same problem. There are multiple directory paths that SA uses > for .cf and .pre files but as long as you don't have a single > self-consistent installation, you should be seeing the same files in > all SA tools. > > I have thought of 2 more possible issues that could cause this without > mangled/diverse installations of Perl and/or SA: > > 4. Restrictive permissions on the directory where the system-wide > local config files reside (/etc/spamassassin) or on the files inside > it which prevent the user running spamd from reading the files. > No, everybody has "read" permission. > 5. Spurious config files in the per-user config directory > (~/.spamassassin) for the user running spamd. > > Off the top of my head, I do not recall what user is used in the > Debian/Ubuntu package to run spamd. > The user is spamd, and there are no per-user rules there.
Ken
