Created attachment 479211 [details] Add pid dir Description of problem: If spampd is running, it should be restarted after sa-update has updated Spamassassin. The way this is currently handled does not work if a service doesn't write a pid file. See https://bugzilla.redhat.com/show_bug.cgi?id=559954 Version-Release number of selected component (if applicable): spampd-2.30-10 How reproducible: Always Steps to Reproduce: 1. Start spampd 2. Wait until Spamassassin is updated running sa-update 3. Actual results: Spampd is not restarted. Expected results: Spampd should be restarted after the update. Additional info: We are using our own Spamassassin and Spampd RPMs which are different from the Fedora/RedHat packages. I just patches current Fedora files to do the same we do in our packages, but it's untested because I'm not using the Fedfora packages.
Created attachment 479212 [details] Add pid dir
This bug appears to have been reported against 'rawhide' during the Fedora 19 development cycle. Changing version to '19'. (As we did not run this process for some time, it could affect also pre-Fedora 19 development cycle bugs. We are very sorry. It will help us with cleanup during Fedora 19 End Of Life. Thank you.) More information and reason for this action is here: https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora19
This is still a problem in F-20. In fact, every time spampd service is shut down, it complains that the pid cannot be removed (because /run is not writeable by spampd).
Oh and the patches should reflect the fact that pid files now live in /run, I think.
(In reply to Bojan Smojver from comment #3) > This is still a problem in F-20. > > In fact, every time spampd service is shut down, it complains that the pid > cannot be removed (because /run is not writeable by spampd). See: https://bugzilla.redhat.com/show_bug.cgi?id=1038388#c3 Basically, instead of mucking about with PID (which will cause the need to have temporary directory created, SELinux shenanigans etc.), we just don't have the PID and let systemd do its magic. Of course, spamassassin would then have to check for running spampd properly. Like this: service spampd status >/dev/null 2>&1 && <do something here>
spampd-2.30-16.fc20 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/FEDORA-2014-0705/spampd-2.30-16.fc20
spampd-2.30-16.fc20 has been pushed to the Fedora 20 stable repository. If problems still persist, please make note of it in this bug report.