Bug 605584 - Cups socket in endless loop consuming 100% CPU cycles
Cups socket in endless loop consuming 100% CPU cycles
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: cups (Show other bugs)
5.5
All Linux
low Severity medium
: rc
: ---
Assigned To: Tim Waugh
qe-baseos-daemons
:
Depends On:
Blocks: 1276772
  Show dependency treegraph
 
Reported: 2010-06-18 06:29 EDT by Simon Matter
Modified: 2015-10-30 16:20 EDT (History)
4 users (show)

See Also:
Fixed In Version: cups-1.3.7-24.el5
Doc Type: Bug Fix
Doc Text:
In some circumstances the standard CUPS backends (which transfer data to the printer) could get stuck in a loop consuming CPU cycles. This has been fixed by adjusting the main data processing loop shared by all the backends.
Story Points: ---
Clone Of:
: 1276772 (view as bug list)
Environment:
Last Closed: 2011-01-13 18:29:39 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
CUPS Bugs and Features 3001 None None None Never
CUPS Bugs and Features 3622 None None None Never
Red Hat Product Errata RHBA-2011:0095 normal SHIPPED_LIVE cups bug fix update 2011-01-12 12:21:21 EST

  None (edit)
Description Simon Matter 2010-06-18 06:29:17 EDT
Description of problem:
On a busy cups server printing to a number of HP JetDirect devices over unstable links it happens from time to time that some socket process of cups keeps hanging around in a endless loop consuming as much CPU cycles as it can.

Version-Release number of selected component (if applicable):
cups-1.3.7-18.el5

How reproducible:
Not so easy because in our environment it usually takes some days until the problem shows up.

Steps to Reproduce:
1. Run cups server with HP JetDirect devices
2. Use it a number of days
3. Suddenly you may find a socket process going in an endless loop
  
Actual results:
No such process should ever show up

Expected results:
If such a process shows up it should at least run a bit nice and not consume to many cycles

Additional info:
From what I understand Cups Patch 3001 does exactly that and we never had the problem again since applying it to our cups-1.3.7-18.el5 rpm since more than a month. I strongly recommend to add it to RHEL.

The patch is here: http://www.cups.org/strfiles/3001/str3001.patch
Comment 4 Simon Matter 2010-08-11 01:28:28 EDT
I just saw that new cups packages have been released but without this bug being fixed. That's really sad because this patch has made the difference for our print server. Without it I had so manually kill hanging and CPU consuming CUPS (socket) processes every other week or so. Since applying the patch some moths ago we didn't have a single issue and the server works as expected.
Our environment is not so exotic, we have 20 printers configured and the issue happens with HP LaserJet 4050 and 4100 devices.
Comment 5 Tim Waugh 2010-08-11 05:51:57 EDT
Simon: we do plan to fix this CUPS bug (and several others) in the next scheduled update.  There were some other fixes that were ahead in the queue.
Comment 6 Tim Waugh 2010-09-23 12:23:39 EDT
    Technical note added. If any revisions are required, please edit the "Technical Notes" field
    accordingly. All revisions will be proofread by the Engineering Content Services team.
    
    New Contents:
In some circumstances the standard CUPS backends (which transfer data to the printer) could get stuck in a loop consuming CPU cycles.  This has been fixed by adjusting the main data processing loop shared by all the backends.
Comment 10 errata-xmlrpc 2011-01-13 18:29:39 EST
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHBA-2011-0095.html

Note You need to log in before you can comment on or make changes to this bug.