Milter-greylist

On 2013-12-06 02:12, manu@... wrote:
> Jim Klimov <jimklimov@...> wrote:
>
>  > I am ready to accept that this may be some glitch of Solaris 10u8 x86
>  > involved as the platform; but still - does anyone have any ideas how
>  > to fix or work-around this?
>
> How is it implemented in p0f code? select(2) or poll(2) loop? Perhaps
> there is something wrong with the timeout?

It is a poll with a 250 msec timeout, as can be seen in p0f.c:874
function live_event_loop() - the code calls poll(), then interprets
its results and acts on them with a series of switch'es:

   while (!stop_soon) {

     s32 pret, i;
     u32 cur;

     /* We use a 250 ms timeout to keep Ctrl-C responsive without 
resortng to
        silly sigaction hackery or unsafe signal handler code. */

poll_again:

     pret = poll(pfds, pfd_count, 250);
...


Ultimately, by line 973, it determines that there is some data
toread() from one file descriptor or another. However, in the
pathological case, the reads return zero bytes, and there is
always a flag up that something can be read, so it becomes a
full-speed infinite loop.

I read up a bit on this yesterday, and it seems to be a proper
solution to close the connection if read() returns zero bytes
while poll() is signalling that "something" is available.

//Jim