On Thu, Nov 11, 2004 at 11:05:43AM +0100, Thomas Lamy said: > Robert S schrieb: > > >I have just upgraded to clamav-milter_0.80-5 on my Debian Woody system. > >When I run > >"/etc/init.d/clamav-milter stop" it hangs. When I do a "ps ax" it says > >"sleep 0.1". Looks as if the offending line something like this: > > > > if [ -n "$PID" ]; then > > start-stop-daemon -q -K -o -p $PIDFILE $DAEMON > > while [ -d /proc/"$PID" ]; do sleep 0.1; done > > > >I think that /proc/"$PID" isn't going away and its staying in the loop > >indefinitely. > > > >I had a similar problem with the last debian release: "start-stop-daemon" > >wasn't killing the process. > > > >I've had to go back to the old hack of killing "daemon" and all instances > >of > >clamav-milter. > > > >Has anybody had similar problems? Any fixes? > > > Please have a look at Debian bug #278198 > (<http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=278198>) for an > in-deep discussion of what's going on/wrong there. I'm sure Stephen Gran > (the pkg maintainer) will come up with a new revision (and a woody > backport) RSN.
What kernel are you running? (I'm asking Robert, obviously). The short version is that I have found through trial and error that the 2.4 series of linux kernels don't implement threads that well - each thread has a different PID (instead of more properly appearing as the same PID, but with a different LWP ID), and inter-thread signal communication is not very quick. 2.6 handles this much better. So, when start-stop-daemon (or daemon) sends a kill signal, it ends up signalling the wrong thread, and it takes a long time for the signal to work. Hence the parent stays around for a long time, and the shutdown takes a long time to happen. The alternative is just to send a kill signal and move on, but then you have problems on restart if the old process hasn't died yet. The woody backport out there has my first hackish and totally non-portable attempt to work around this - a better and portable one is sitting on my development machine while I think about this some more. The new one borrows liberally from squid's shutdown script, and will tell you that it's still waiting for the process to go away, so it at least won't appear to 'hang', although it may still take some time. So, for Robert, can you do a couple of things for me? Let me know the output of: uname -a ps -el | egrep '(PID|clamav-milter)' And also try running the milter (and clamd - they're tied together unfortunately, in this) without daemon and let me know how a shutdown goes? To do this, stop clamd and the milter, comment out Foreground, and start them both again. Then try: time /etc/init.d/clamav-milter stop. Reply either on or off list - this is more of packaging issue than a clamav one, strictly, so I don't mind taking it to private email. Thanks, -- -------------------------------------------------------------------------- | Stephen Gran | Just because you're paranoid doesn't | | [EMAIL PROTECTED] | mean they AREN'T after you. | | http://www.lobefin.net/~steve | | --------------------------------------------------------------------------
pgpl6CiepROsG.pgp
Description: PGP signature
_______________________________________________ http://lists.clamav.net/cgi-bin/mailman/listinfo/clamav-users