fre 2010-04-02 klockan 15:41 -0300 skrev Marcus Kool: > strange indeed, but this is strace output with which I am not very familiar. > Strace should print the whole array that it uses as argument to > epoll_wait or just prints the first element ? (and the 2nd argument > could be FD 27)
For epoll_wait it prints the valid entries in the result array, which has length 1 in this case (see return value last on the line). > > Can you please use cachemgr to view the current filedescriptors page to > > note what fd 23 & fd 27 is being used for? > > I restarted Squid and now it does not loop... > The lsof output in the original email is of little help: A little. Both are pipes. And it's not unlikely these pipes have the same fd assignments now after restart. What does cachemgr say now? > squid 13665 squid 20w REG 9,3 1478687 4718702 > /local/squid/logs/access.log > squid 13665 squid 21r FIFO 0,6 1723502 pipe > squid 13665 squid 22w REG 9,3 30400812 4718715 > /local/squid/cache/swap.state > squid 13665 squid 23r FIFO 0,6 1723506 pipe > squid 13665 squid 24w FIFO 0,6 1723503 pipe > squid 13665 squid 25u IPv4 1723505 TCP *:squid > (LISTEN) > squid 13665 squid 26w FIFO 0,6 1723506 pipe > squid 13665 squid 27r FIFO 0,6 1723507 pipe > FD 27 ***** > squid 13665 squid 28w FIFO 0,6 1723507 pipe > squid 13665 squid 29u IPv4 1771231 TCP > srv004:squid->xxx > (ESTABLISHED) > > It seems that FD 27 and 28 point to the same object (as FD 23 and FD 26) Hmm.. > The strace output lists the parameters at the call time and > we do not see the return values (only the function return value). Should be return values. strace knows how epoll_wait works. > Is it possible that FD 27 has an EPOLLERR condition instead of a > EPOLLIN condition and the loop is caused by trying to do read() on FD 27 ? > (I do not see any check for a return of EPOLLERR in the sources). read should not return EAGAIN if there is an pending error condition. Regards Henrik
