> > A second and more defensive measure is to issue a non-blocking read on
> > the pipe to drain all qmail-queue bytes *prior* to the todo
This is the solution I eventually used. Works like a charm. I've
appended the patch so that it gets into the archives. Variations from
the original post inclu
(To follow up on my own post)
> In other words, in the tiny window that qmail-send leaves for the
> kernel to flush the pipe, there is always at least one qmail-queue
> process with the trigger open. Ergo a resource burning spin that
> degenerates if the injection rate is high and regular (exactl
(I originally found this problem on a very busy FreeBSD 4.3 system
running with the bigtodo patch - it is much less likely to occur with
a standard qmail.)
First some background regarding trigger. When qmail-queue has a mail
for qmail-send it opens the named pipe, trigger, writes a byte to it,
cl
