On Mon, Jan 31, 2005 at 10:50:29PM +0800, imacat said: > On Sun, 30 Jan 2005 22:35:47 -0500 Stephen Gran <[EMAIL PROTECTED]> > wrote: > > The debian init script has been sending the kill signal to the whole > > process group for some time, and now it checks if the pid is > > negative first. If htere is a problem with the package supplied > > init script, let me know, and I'll merge patches or otherwise try to > > work on it. I do > > Than you for your hint, though I cannot access > http://people.debian.org/~sgran/debian now. (people.debian.org > and packages.debian.org are down?) > > I wrote my own init script (personal taste, something like > Linux-from-scratch). Currently I'm doing > > echo $((0-$(<$PIDFILE))) > $PIDFILE > > after the clamav-milter is started, since a positive PID file is > more useful. I can use it to check if the daemon is still > running, maybe communicate with it, doing this and that, bla bla > bla. From what you said you made a similar approach, too. Then I > don't see the use of a "negative PID". (Maybe it's for Red Hat > descendants?)
When you send a signal to the negative of the pid, it is actually sent
to the entire process group. This is normally not necessary, but the
thread implementation in linux 2.4 is pretty bad, and it can take a long
time for the milter to respond to the signal. Think of it like this:
parent thread writes pidfile with it's pid, spawns some helper threads
one listens for signal events, several poll for events
Due to poor design decision, each thread gets a seperate pid, instead of
a seperate LWP ID (lightweight process) This is a kernel/pthreads
problem, not clam problem, so there is not much they can do here.
( This is not completely accurate, as any oversimplification has to be
at least slightly wrong, but you get the picture).
The problem is that when you kill `cat $pidfile`, you don't end up
signalling the thread that is listening for signal events, and it has to
be communicated over to that thread by the thread that wrote the pid
file. This inter thread communication is slow at best on linux 2.4
kernels, but quite snappy on 2.6. All threads also correctly share a
pid, but have seperate LWP IDs on 2.6. So, the workaround is to send a
kill to -${pid}, which sends that signal to all threads in the process
group, including the ones polling for events and the one listening for
signals. This means the signalling thread gets the signal right away,
and it works much quicker.
I had already resorted to the hack of sending the signal to the negative
of the pid due to this poor thread handling, and so I was a little
surprised, to say the least, when I was suddenly sending a kill to
--${pid}, as it caused rather unpredictable and dangerous behavior.
> > agree that writing a negative pdi file seems wrong, however.
>
> If that is the case, could somebody forward this discussion thread
> to the maintainer of ClamAV? I would really like to hear the idea
> behind this change ("negative PID"). Or maybe we can change it
> back again?
They are listening, and we have in fact already had this discussion.
They disagree, or at least last time they said anything about it they
did. To me, it seems like an unecessary hack, that comes with some
danger in it (the magic kill -signal -1 will kill all processes except
init), and is only necessary for a version of the linux kernel that is
on it's way out, as 2.6 stabilizes. I would have rather had a note in
the README about this problem on 2.4 kernels, with a short 'how to work
around' section.
Take care,
--
--------------------------------------------------------------------------
| Stephen Gran | When things go well, expect something |
| [EMAIL PROTECTED] | to explode, erode, collapse or just |
| http://www.lobefin.net/~steve | disappear. |
--------------------------------------------------------------------------
pgpDc3a59KiPZ.pgp
Description: PGP signature
_______________________________________________ http://lists.clamav.net/cgi-bin/mailman/listinfo/clamav-users
