Bob & John.... Thanks so much for the info. But as if I wasn't dazed &
confused enough already, I have discovered a new variable to the whole
thing. I have set up a couple of sandbox EC2 instances just to play. I
didn't realize it at first, but one is AWS Linux 1 and the other is AWS
Linux 2. And the whole startup file structure is different between the
two. The Linux 1 env does indeed have /etc/init.d/spamassassin. But I
don't see anything that looks like it's setting a user to 'spamd'. In
the Linux 2 env, I have:
/usr/lib/systemd/system/spamassassin.service that starts /usr/bin/spamd
using options file /etc/sysconfig/spamassassin
I read elsewhere that a "User=" parm can be added to a .service file.
But the one I have has nothing related to user. The usr/bin/spamd file
is nearly 4000 lines. It's setting the folders, logging, etc. So it
appears to be the main script. But from my understanding, the user
would already be set prior to this script being called.
Kris D suggested I add "-u spamd" to the options file. But I looked in
/etc/passwd and there is no spamd user. There is no user defined that
even remotely resembles an id that SA would have created. (This is all
on the Linux 2 instance, haven't checked the Linux 1 instance yet).
I can hack around and add a spamd user and add the parameters to make
spamd run as that id and then check the logs to see where SA is looking
now for bayes_*. But that seems to be a fairly wide departure from an
out-of-the-box experience. Does this seem right? I always very
cautious before claiming "bug". But it is possible some critical items
were left out of the AWS Linux 2 install package for SA? Should I go
ahead and add the spamd user?
Thx again.
Jerry
