On 9/16/2015 3:30 AM, Nathan wrote:
On 16/9/2015 12:05 AM, Bowie wrote:
It sounds like it might be an issue with your init script. Check the init
script for spamassassin and see if it is starting spamd with a
'--siteconfigpath' option or similar.
You may also need to check in /etc/sysconfig if your init script pulls anything
from there.
Thanks Bowie for your response, that thought had crossed my mind at some point
also, sorry I failed to mention how it was starting up. I couldn't see any
differences between working and not-working systems here and so I've included
the advised files on how it's set up and how the process is running.
With that said, I've narrowed the issue to be symbolic links, which I had thought I
tested before sending my original message, but I guess not. I've got a btsync folder in
/home that I link my exim and SA configuration files to, it would seem of the 5 servers
configured this way, 3 SA's are having issues following the symbolic links. All the file
permissions seem fine/the same as working and non-working systems. Although with this
development, I've scripted a copy command when the files in /home/btsync change to copy
them to "/etc/mail/spamassassin" and restart the SA service. This stream lines
future changes even further, so win win really.
I would be great to work out why symbolic links are stuffing up in 60% of my SA
installs, but I think my care level is running low now. Thank you again Bowie
for your support is has been greatly appreciated.
selinux? I'm not an expert in that area, but I know it can cause some
really strange problems if it's not set up right.
This still leaves one system in an interesting state, that seems to read local.cf and
addresses.cf files but ignores the latestspam.cf. I've tried renaming it to aaaaa.cf
created a new file called newspam.cf and pasted the data into it, but it continues to
ignore the data within. Yet moving this to the local.cf file, no worries it blocks on
this. I've confirmed that "spamassassin --lint -D" sees the file but it
doesn't seem to read it.
........
Sep 16 15:13:11.529 [10089] dbg: config: using "/etc/mail/spamassassin" for
site rules dir
Sep 16 15:13:11.529 [10089] dbg: config: read file
/etc/mail/spamassassin/addresses.cf
Sep 16 15:13:11.529 [10089] dbg: config: read file
/etc/mail/spamassassin/blocknathan.cf
Sep 16 15:13:11.539 [10089] dbg: config: read file
/etc/mail/spamassassin/latestspam.cf
Sep 16 15:13:11.539 [10089] dbg: config: read file
/etc/mail/spamassassin/local.cf
.........
This is even further confirmed by creating a new file called blocknathan.cf
with only a single blacklist_from that is ignored also. Is there any further
debugging where you can see what it's read, or why it's not? What is making
addresses.cf special? and why can I move it to zzzaddresses.cf and it still
works :( I'm thinking a rebuild is due for this machine, as I can't back it up
live with VMware ESXi snapshot, as it was poorly imported, so unless anyone
else has any ideas I might just step up the migration.
[root@mail2 ~]# ps aux | grep spamd
root 43121 0.0 4.5 244384 32116 ? Ss 05:05 0:06 /usr/bin/spamd
-d -c -m5 -H -r /var/run/spamd.pid
Try running spamd manually in debug mode. That way you can see exactly
what it's doing. Just remove the -d and add -D.
# service spamassassin stop
# /usr/bin/spamd -D -c -m5 -H -r /var/run/spamd.pid >
/tmp/spamd-debug.log 2>&1
Run spamc with a test file from another window to confirm the problem
still exists. Once you are done testing, kill the debug version with
Ctrl-C and 'service spamassassin start' to get running normally again.
Go check the log file to see what files it loaded and whether any errors
were generated.
--
Bowie
