(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 (exactly the > situation for the servers I noticed this on). > ... > Fortunately there are a couple of remedies. > > At the very least, the flush window can be made substantially larger > by closing trigger as soon as the select returns. This of course is not a good idea as it means that any qmail-queue notify will be lost while trigger is closed. So the closed-window size is a catch-22. Keep it small and a busy system may spin as described. Make it larger and you increase the probably of missing a notify from qmail-queue. > 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 > scan. Perhaps both of these could be done in the trigger_pull > routine. I've appended a patch that gives the idea in code (it's > untested). I still think this might be a viable solution. In fact I wonder whether qmail-send can simply keep the pipe open and do a non-blocking read to drain the notifys rather than rely on the open/close flush semantics. That way there is no close-window at all, so losing a notify becomes impossible rather than unlikely, it's simpler code, it eliminates the false triggers I'm seeing and probably creates less load on the OS by avoiding those repeated opens and closes. Regards.
