From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5) Gecko/20041111 Firefox/1.0 Description of problem: I use spamassassin + clamav + sagator. When the system is working and under some (not too high) load restarting spamassassin fails. Maybe bind's workarround/fix should be used (sleep 5 seconds in the rc script). Version-Release number of selected component (if applicable): spamassassin-3.0.1-0.FC3 How reproducible: Sometimes Steps to Reproduce: 1. install spamassassin in FC3 2. give it some work to do 3. service spamassassin restart Actual Results: [root@fc3 ~]# service spamassassin restart Shutting down spamd: [ OK ] Starting spamd: Could not create INET socket on 127.0.0.1:783: Address already in use (IO::Socket::INET: Address already in use) [FAILED] Additional info: It's funny you can even get situations like this one: [root@fc3 ~]# service spamassassin restart Shutting down spamd: [ OK ] Starting spamd: Could not create INET socket on 127.0.0.1:783: Address already in use (IO::Socket::INET: Address already in use) [FAILED] [root@fc3 ~]# service spamassassin restart Shutting down spamd: [ OK ] Starting spamd: [ OK ] if you execute these fast enough.
Hmm, your suggestion of "sleep 5" between stop and start might be a good idea. But first lets ask upstream if there is any better way of ensuring that spamd is completely killed and released the port, which would avoid the need for this kind of ugly hack. This is the snippet from /etc/init.d/spamassassin showing the part that fails to stop the service before returning. stop) # Stop daemons. echo -n "Shutting down spamd: " killproc spamd RETVAL=$? echo [ $RETVAL = 0 ] && rm -f /var/lock/subsys/spamassassin ;; http://people.redhat.com/wtogami/temp/functions killproc is located in this script located at /etc/init.d/functions.
killproc is returning before spamd is fully dead. spamd children are respawning after they are killed before the parent process is dead - although this may not be related to the "fails under load" problem. There are signal handling problems here that need to be investigated upstream in spamd. I'm adding the sleep 5 here as a workaround, as it should avoid trouble in 99% cases. I am willing to guess that "killall -9 spamd" might corrupt databases and is not a solution. Keeping bug open to keep the spamd issues on the radar.
interesting problem. could someone open this upstream?
everyone can, I'll try when I have a bit more free time and add references here and there, but feel free to do so before me :)
I belive it has something to do with http://bugzilla.spamassassin.org/show_bug.cgi?id=2186 ...
I opened http://bugzilla.spamassassin.org/show_bug.cgi?id=4432 with link to this one.
Bug #161785 seems to have a better explanation of the cause of this bug. This is not the fault of spamd itself, but rather the init.d script's codepath to kill spamd. It would be helpful if upstream could look at the excellent explanation in Bug #161785. I am hoping there is a better solution to this problem than the suggested shell script .pid solution suggested in that bug. Wouldn't it be preferable to have a solution where spamd itself returns when it is finished stopping? *** This bug has been marked as a duplicate of 161785 ***