Bug#292480: Confirm bug still present in etch
I'm seeing this on our etch systems as well as our sarge systems.
Since I'm running cups on several hundred systems, I see this happen
on several machines every day. It looks very much, from strace, that
the cups-polld program gets into a tight loop polling the server - it
tries to read data, gets zero bytes and immediately tries again:
recv(6, "", 2048, 0) = 0
gettimeofday({1200333488, 445219}, NULL) = 0
recv(6, "", 2048, 0) = 0
gettimeofday({1200333488, 445565}, NULL) = 0
recv(6, "", 2048, 0) = 0
gettimeofday({1200333488, 445907}, NULL) = 0
recv(6, "", 2048, 0) = 0
gettimeofday({1200333488, 446251}, NULL) = 0
recv(6, "", 2048, 0) = 0
gettimeofday({1200333488, 446588}, NULL) = 0
recv(6, "", 2048, 0) = 0
gettimeofday({1200333488, 446924}, NULL) = 0
recv(6, "", 2048, 0) = 0
gettimeofday({1200333488, 447256}, NULL) = 0
recv(6, "", 2048, 0) = 0
gettimeofday({1200333488, 447587}, NULL) = 0
recv(6, "", 2048, 0) = 0
gettimeofday({1200333488, 447923}, NULL) = 0
ad infinitum. Our cups server is not Debian, but even if there's
breakage at the server side, the client shouldn't do this.
lsof shows that this socket is in CLOSE_WAIT, so it looks like there's
a problem with trying to read from a closed socket:
cups-poll 6688 lp 6u IPv4 577824 TCP
turing.internal.sanger.ac.uk:54594->cupsrv1:ipp (CLOSE_WAIT)
Does any of that help?
Regards,
Tim
--
The Wellcome Trust Sanger Institute is operated by Genome Research
Limited, a charity registered in England with number 1021457 and a
company registered in England with number 2742969, whose registered
office is 215 Euston Road, London, NW1 2BE.
Reply to: