Description of problem: Update to latest spamassassin cause spamd processes to be SIGTERM'd at startup, leads to a repetitive cycle of spawning replacements. No other processes can contact spamd. Version-Release number of selected component (if applicable): spamassassin-3.4.0-3.fc20.x86_64.rpm How reproducible: 100% failure with -d and --socketpath in /etc/sysconfig/spamassassin options Steps to Reproduce: 1. Update to latest spamassassin 2. Restart existing spamd with current /etc/sysconfig/spamassassin options 3. Watch spamd PIDs incrementing using ps aux | grep spam Actual results: Spamd is issued SIGTERM for each child process on startup with -d and --socketpath=/path/ options, leads to continuous respawning of spamd children Expected results: Working spamd processes that can be accessed by other daemons Additional info: Looking at spamassassin 3.4.0 spamd man page it seems that there have been some changes to the spamd options. This could be relevant but I was unable to find a combination of spamd options that avoided this problem.
Can you attach output of: journalctl -b -u spamassassin You should NOT be using -d anymore... it shouldn't be in /etc/sysconfig/spamassassin. If you remove the -d does it work?
I will so that as soon as I've got easy access to the machine. FYI, the spamd options shown here: https://spamassassin.apache.org/full/3.4.x/doc/spamd.html still include -d, I've been using it is my /etc/sysconfig/spamassassin for as long as I've been using SA and Exim and this is the first time it has caused a problem. I assume this is to do with the systemd startup script is it?
Right, to be clear the -d option is still there, just now the systemd unit doesn't want it to be used. It expects to launch it and keep it in the foreground so it can capture all output and doesn't have to deal with racy pid files, etc.
OK, well I decided to bite the bullet and re-upgrade. I see that the /etc/sysconfig/spamassassin.rpmnew file does not have -d in the options. I did notice that before, but didn't instantly recognise why. I have now looked at the changes in the /usr/lib/systemd/system/spamassassin.service file and I see that it has had Type=Forking removed. I have removed the -d option from the /etc/sysconfig/spamassassin options and indeed everything now seems to behave. Perhaps something added to the /usr/share/doc/spamassassin/README files to note this change would be useful?
Not sure too many folks read those things, but I could add something... perhaps to the sysconfig file?
That would make sense, a default file with a comment saying something like "Do not use -d option with systemd" would make people aware of this.
I'll note it in the update, hopefully that will be enough for folks.
spamassassin-3.4.0-3.fc20 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/FEDORA-2014-4171/spamassassin-3.4.0-3.fc20
Oh, could you retract your -1 karma on the update now? (just +1 it)
spamassassin-3.4.0-4.fc20 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/spamassassin-3.4.0-4.fc20
Package spamassassin-3.4.0-4.fc20: * should fix your issue, * was pushed to the Fedora 20 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing spamassassin-3.4.0-4.fc20' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2014-6643/spamassassin-3.4.0-4.fc20 then log in and leave karma (feedback).
spamassassin-3.4.0-4.fc20 has been pushed to the Fedora 20 stable repository. If problems still persist, please make note of it in this bug report.