Red Hat Bugzilla – Bug 720921
cups-polld busy-loops in recvfrom() after suspend/resume
Last modified: 2011-09-09 01:24:43 EDT
Created attachment 512603 [details] excerpt of strace attached to affected cups-polld process Description of problem: Since updating to cups-1.4.7-3.fc15.x86_64, after resuming from Suspend-to-RAM, cups-polld burns 100% CPU, strace shows it's busy-looping in recvfrom(). Version-Release number of selected component (if applicable): cups-1.4.7-3.fc15.x86_64 cups-1.4.7-6.fc15.x86_64 <-- all traces made with this one How reproducible: Reproducible Steps to Reproduce: 1. Have BrowsePoll lines in cupsd.conf 2. Suspend to RAM 3. Resume Actual results: cups-polld busy loops in recvfrom() burning 100% CPU Expected results: Not sure, but not the above :-) Additional info: I have two BrowsePoll lines, one for the print server in the office, one for the one at home. Right now (being in the office), only the one for the office print server shows the described behavior.
Created attachment 512605 [details] Output of lsof attached to the affected process
List of cups processes: nils@gibraltar:~> ps auxw|grep cups| grep -v grep lp 10548 0.0 0.0 58320 1604 ? S 10:02 0:00 /usr/lib/cups/notifier/dbus dbus:// lp 10549 0.0 0.0 58320 1608 ? S 10:02 0:00 /usr/lib/cups/notifier/dbus dbus:// root 18319 0.0 0.0 194960 2464 ? Ss Jul12 0:01 cupsd -C /etc/cups/cupsd.conf lp 18320 0.0 0.0 58320 1064 ? S Jul12 0:00 cups-polld 10.0.0.2 631 30 631 lp 18321 3.1 0.0 64704 1316 ? R Jul12 45:27 cups-polld cups.str.redhat.com 631 30 631 nils@gibraltar:~>
Created attachment 512608 [details] gdb backtrace of the affected process
Created attachment 512609 [details] /etc/cups/cupsd.conf
Created attachment 512611 [details] gdb affected process, up to frame #2, keep hitting next
Created attachment 512612 [details] gdb affected process, print *http
Please try cups-1.4.7-7.fc15.
Looks good to me, both cups-polld instances seem to be in a blocking system call instead of busy looping, according to strace. Thanks for the quick help!
*** Bug 722259 has been marked as a duplicate of this bug. ***
(In reply to comment #9) > *** Bug 722259 has been marked as a duplicate of this bug. *** - probably the same bug, only I didn't do suspend/resume...
cups-1.4.7-8.fc14 has been submitted as an update for Fedora 14. https://admin.fedoraproject.org/updates/cups-1.4.7-8.fc14
cups-1.4.7-9.fc15 has been submitted as an update for Fedora 15. https://admin.fedoraproject.org/updates/cups-1.4.7-9.fc15
Package cups-1.4.7-8.fc14: * should fix your issue, * was pushed to the Fedora 14 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing cups-1.4.7-8.fc14' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/cups-1.4.7-8.fc14 then log in and leave karma (feedback).
cups-1.4.8-1.fc15 has been pushed to the Fedora 15 stable repository. If problems still persist, please make note of it in this bug report.
cups-1.4.8-2.fc14 has been submitted as an update for Fedora 14. https://admin.fedoraproject.org/updates/cups-1.4.8-2.fc14
Doesn't this patch break things (like printing) if http authorization is required to access cups server?
I don't believe so. Authorization is handled in httpSendRequest() (http->status would be HTTP_UNAUTHORIZED in that case, not HTTP_ERROR).
Here we have a problem with this patch but didn't debug it deeply yet, so you can ignore this report since it's not on fedora (but most likely fedora people will also hit this). "This patch causes auth to fail in a strange way. I have, in my cupsd.conf on server: <Location /printers/lp2040a> Encryption ifRequested AuthType Default Require valid-user Order allow,deny Allow localhost Allow ip1... .... </Location> Without this patch 'lp' on client nicely asks for a password and does its job, with this patch 'lp' asks for a password and then prints 'lp: Unknown' and nothing gets sent to printer. It's probably caused by the server returning a HTML page in IPP response when it claims that auth is required, and this patch makes client to trip on this, instead of just ignoring it. Attached are debug logs (CUPS_DEBUG_LEVEL=9) from running command './lp -d lp2040a /etc/host.conf' with and without this patch applied."
Created attachment 520594 [details] printing with problematic patch
Created attachment 520595 [details] printing without problematic patch
cups-1.4.8-2.fc14 has been pushed to the Fedora 14 stable repository. If problems still persist, please make note of it in this bug report.