Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 451101 - CUPS drops multi-part jobs from upstream servers
Summary: CUPS drops multi-part jobs from upstream servers
Alias: None
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: cups
Version: 5.2
Hardware: i386
OS: Linux
Target Milestone: rc
: ---
Assignee: Tim Waugh
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 2008-06-12 19:25 UTC by Jason McCormick
Modified: 2009-01-20 21:59 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2009-01-20 21:59:31 UTC
Target Upstream Version:

Attachments (Terms of Use)

System ID Priority Status Summary Last Updated
Red Hat Product Errata RHEA-2009:0201 normal SHIPPED_LIVE cups enhancement update 2009-01-20 16:06:07 UTC

Description Jason McCormick 2008-06-12 19:25:39 UTC
Description of problem:

The CUPS version shipping with RHEL 5 (CUPS 1.2.x) has a problem whereby a
server using IPP receives a job submission from another CUPS server will only
print the first part of a job.  I have multiple CUPS servers.  One CUPS server
is only a set of queues that the target of which is another CUPS server via IPP
(i.e. the "upstream server").  Another CUPS server (i.e. the "master server")
talks directly to the printers via their native protocol (mostly JetDirect).  
All queues on the "master" server have a burst page, all queues on the
"upstream" servers do not.  

A user printing via IPP directly to a queue on the "master" can complete any job
just fine.  The use case diagram is:

Client --> CUPS Master --> Printer

However if a client of the "upstream" server submits a job to a queue there that
is directly handed off to another IPP queue on the "master" server, only the
burst page appears.  The use case diagram is:

Client --> CUPS Upstream -->>IPP>>--> CUPS Master --> Printer

I've verified that the CUPS Master receives the job from the upstream server in
two parts, the burst page and then document.  These files are present in
/var/spool/cups if you retain the jobs.  However the user submitting the file
only gets the burst page.  If I go into the CUPS control panel and chose to
reprint the job, the entire job prints out.

I rebuild the FC9 RPM of CUPS 1.3.7 and it functions fine with no configuration
changes.  I discovered this after an upgrade from AS3 and CUPS 1.1.x where this
setup also functioned.  I tried obtaining the last CUPS 1.2.12 from and
it also exhibits the problem so it's definitely a problem with the 1.2.xx series.

Version-Release number of selected component (if applicable):

cups-1.2.4* on EL5

How reproducible:


Steps to Reproduce:
1.  Create queues on one CUPS server that print directly to printers.  Queus
should have burst pages/cover sheets.
2.  Create queues on a second CUPS server that print to the first servers queues.
3.  Print a page as a client of the second CUPS server.  The file
is a good testing candidate.

Actual results:

Burst page only appears

Expected results:

Burst page followed by document

Comment 1 Tim Waugh 2008-06-13 14:48:44 UTC
I can reproduce this behaviour when the CUPS Master queue has a 'file:' device
URI.  If a backend process is used all is well.

Comment 2 Jason McCormick 2008-06-13 14:51:47 UTC
My master queues area all socket://  device URIs but I would expect file:// and
socket:// to receive roughly the same treatment.

Comment 3 RHEL Product and Program Management 2008-06-13 15:07:18 UTC
This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux maintenance release.  Product Management has requested
further review of this request by Red Hat Engineering, for potential
inclusion in a Red Hat Enterprise Linux Update release for currently deployed
products.  This request is not yet committed for inclusion in an Update

Comment 4 Tim Waugh 2008-06-13 15:30:30 UTC
No, they are distinct types of queue.  For socket: queues a separate process
(/usr/lib/cups/backend/socket) is launched as part of the pipeline; for file:
queues this is not done, and a different code path is followed.

Please provide the output of 'lpstat -s' from the master server, as well as (if
you are able) a PPD from an affected queue on that server, from /etc/cups/ppd. 

Comment 9 Jason McCormick 2008-07-18 16:51:42 UTC
Sorry, I forgot to reply to this until I just got a change-of-stat notice.  I
don't have the server in the problematic configuration anymore.  It's running a
hand-built RPM of the latest CUPS release on EL5.

Comment 13 errata-xmlrpc 2009-01-20 21:59:31 UTC
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.

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