On Wed, 1 Jun 2011 16:31:45 -0700, Phil Oester wrote:
I'm having a problem similar to the one described here (and in bug
3189):
http://squid-web-proxy-cache.1019090.n4.nabble.com/Squid-loops-on-epoll-read-gettimeofday-td1695367.html
where occasionally on a fresh start, squid (3.1.1[12]) will loop
between epoll_wait and read as follows, using 100% cpu:
epoll_wait(6, {{EPOLLIN, {u32=103, u64=7198046948199235687}}}, 8192,
55) = 1
read(115, 0x7fffa78584f0, 256) = -1 EAGAIN (Resource
temporarily unavailable)
epoll_wait(6, {{EPOLLIN, {u32=103, u64=7198046948199235687}}}, 8192,
55) = 1
read(115, 0x7fffa78584f0, 256) = -1 EAGAIN (Resource
temporarily unavailable)
epoll_wait(6, {{EPOLLIN, {u32=103, u64=7198046948199235687}}}, 8192,
55) = 1
read(115, 0x7fffa78584f0, 256) = -1 EAGAIN (Resource
temporarily unavailable)
In the thread noted above, Henrik wondered why epoll_wait was
returning
one fd (fd 103), and read was acting upon another (fd 115). He asked
for cachemgr output showing what each fd was being used for. In my
case,
both fd refer to similar items:
103 Pipe 0 0* 0 async-io
completetion event: main
115 Pipe 0 0* 0 async-io
completetion event: main
Is it possible this is a simple off by one error within aufs?
A stop/start on squid usually solves this, but occasionally the newly
started
instance has the same problem and I have to restart multiple times.
Any ideas?
The miss-spelling points straight at CommIO::Initialise() in
src/comm.cc. Which makes that pipe the AIO callback.
I think off-by-on there would possibly make AIO break completely.
Could write events on a pipe() trigger an event signal on both FD?
CommIO::DoneReadFD and CommIO::DoneFD need to be checked to see if they
both match the expected FD above.
Amos
