[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#634325: marked as done (cups-polld does not properly handle network errors, uses 100% CPU in loop)

Your message dated Wed, 12 Jun 2013 14:08:26 +0200
with message-id <201306121408.26625.odyx@debian.org>
and subject line Re: cups-polld does not properly handle network errors, uses 100%
has caused the Debian Bug report #634325,
regarding cups-polld does not properly handle network errors, uses 100% CPU in loop
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner@bugs.debian.org
immediately.)


-- 
634325: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=634325
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems
--- Begin Message --- 
Package: cups
Version: 1.4.7-1
Tags: patch

If cups-polld runs into a network error after connecting to a remote IPP
server while polling, it will wind up in an endless loop using 100% CPU.
This can be quickly tested using the following procedure:

  1. Configure cups with BrowsePoll to poll a remote server
  2. Use strace on the cups-polld instance for the remote server
  3. Use iptables to block responses from the server, e.g.
      iptables -I INPUT 1 -p tcp -s 192.2.0.2 --sport ipp -j REJECT --reject-with tcp-reset
  4. Wait for the strace to show that cups-polld is blocking in recvfrom
  5. Use iptables to send RST on packets to the server, e.g.
      iptables -I OUTPUT 1 -p tcp -d 192.2.0.2 --dport ipp -j REJECT --reject-with tcp-reset
  6. Wait until TCP decides it has waited too long for an ACK and
     resends the packet.
  7. Observe that the recvfrom now fails with ECONNRESET, and then
     strace outputs lines like the following until the process is killed:
      recvfrom(6, "", 2048, 0, NULL, NULL)   = 0

Note that step 5 may be skipped, in which case you have to wait until
the TCP connection times out in step 6. In the wild, this sort of
situation may occur if the machine is suspended or if the network
connection goes down at the wrong time.

This appears to be the same as
https://bugzilla.redhat.com/show_bug.cgi?id=720921, and the patch
extracted from
http://pkgs.fedoraproject.org/gitweb/?p=cups.git;a=commitdiff;h=a8d53773cf4e1014d4fbb065ab6f0ea480184de9
seems to work. I've attached the actual patch to this message, which
should be importable with quilt import -p1.

--- a/cups/request.c
+++ b/cups/request.c
@@ -395,7 +395,7 @@
   {
     status = httpUpdate(http);
   }
-  while (http->state == HTTP_POST_RECV);
+  while (status != HTTP_ERROR && http->state == HTTP_POST_RECV);
 
   DEBUG_printf(("2cupsGetResponse: status=%d", status));

--- End Message ---
--- Begin Message --- 
Version: 1.5.3-5

Le mercredi, 12 juin 2013 13.41:01, Samuel Wolf a écrit :
> Hi,
> 
> can not reproduce the problem.
> In my eyes it is fixed in debian wheezy release.

Cool, thanks, marking as such.

Cheers,

OdyX

--- End Message ---
Reply to: