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 |                                         |
 --------------------------------------------------------------------------

Attachment: pgpl6CiepROsG.pgp
Description: PGP signature

_______________________________________________
http://lists.clamav.net/cgi-bin/mailman/listinfo/clamav-users

Reply via email to