Bug 677136 - Job with multiple files gets removed after backend fails
Summary: Job with multiple files gets removed after backend fails
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: cups
Version: 5.3
Hardware: All
OS: Linux
unspecified
high
Target Milestone: rc
: ---
Assignee: Tim Waugh
QA Contact: qe-baseos-daemons
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-02-13 16:02 UTC by Opher Shachar
Modified: 2013-03-11 15:23 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2013-03-11 15:23:29 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)
suggested patch (648 bytes, patch)
2011-02-13 16:15 UTC, Opher Shachar
no flags Details | Diff

Description Opher Shachar 2011-02-13 16:02:30 UTC
Description of problem:
This is similar to bug #432001 and bug #506257 for the case that the job is made _pending_ or _held_ after the backend fails.

When a file is printed with a banner (which makes it a multi-file job) or two or more files are printed together, and then the backend fails, the print job is incorrectly marked as completed and therefore removed. This occurs because when CUPS retries the job it *only* forks the filter for the second file, instead of forking the backend and the filter chain for all the files.
The problem only affects multi-file jobs.


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

How reproducible:
Always

Steps to Reproduce:
1. set CUPS' logging level to debug
2. create printer of type "textonly" with backend 'lpd://192.168.1.2/lp' (a non-existent ip in the local subnet)
3. print a multi-file job
   lp -d myprinter file1.txt file2.txt
4. look in error_log for the PID of the backend
5. kill <PID of backend>
6. job is placed in HELD status for 'JobRetryInterval' seconds
7. job is automatically released by CUPS 
8. job is marked completed!
  
Actual results:
In step 7 CUPS *only* starts '/usr/lib/cups/filter/textonly' for the second file. It does not start the filter for the first file nor the backend!

Expected results:
Job is restarted from first file and backend also started.

Additional info:
If the destination is a 'class' then in step 6 above job is placed in PENDING status, then continues immediately (by design, there's no retry interval) with steps 7 and 8.

Comment 1 Opher Shachar 2011-02-13 16:15:51 UTC
Created attachment 478487 [details]
suggested patch

Comment 2 Tim Waugh 2011-02-14 09:49:33 UTC
Thanks for reporting this, and for the patch.

Comment 3 Tim Waugh 2011-02-18 16:31:57 UTC
How to reproduce:

1. Create the queue, setting printer-error-policy to retry-job:

lpadmin -p myprinter -v lpd://192.168.1.2/lp -m textonly.ppd \
        -o printer-error-policy=retry-job -E

2. Submit a multi-file job:

lp -d myprinter /etc/fstab /etc/fstab

3. Wait until the job starts (sleep 1)

4. Find PID of backend and kill it:

set $(ps xf | grep [l]pd)
kill $1

5. Wait until the job is retried (default is 5 minutes)... look for "Started filter" in /var/log/cups/error_log

Comment 5 RHEL Program Management 2011-05-31 14:14:52 UTC
This request was evaluated by Red Hat Product Management for
inclusion in the current release of Red Hat Enterprise Linux.
Because the affected component is not scheduled to be updated in the
current release, Red Hat is unfortunately unable to address this
request at this time. Red Hat invites you to ask your support
representative to propose this request, if appropriate and relevant,
in the next release of Red Hat Enterprise Linux.

Comment 6 RHEL Program Management 2012-04-02 10:33:09 UTC
This request was evaluated by Red Hat Product Management for inclusion
in a Red Hat Enterprise Linux release.  Product Management has
requested further review of this request by Red Hat Engineering, for
potential inclusion in a Red Hat Enterprise Linux release for currently
deployed products.  This request is not yet committed for inclusion in
a release.

Comment 9 RHEL Program Management 2012-10-26 18:18:53 UTC
This request was evaluated by Red Hat Product Management for
inclusion in the current release of Red Hat Enterprise Linux.
Because the affected component is not scheduled to be updated
in the current release, Red Hat is unable to address this
request at this time.

Red Hat invites you to ask your support representative to
propose this request, if appropriate, in the next release of
Red Hat Enterprise Linux.

Comment 10 Jiri Popelka 2013-03-11 15:23:29 UTC
RHEL-5.10 (the next RHEL-5 minor release) is going to be the first production phase 2 [1] release of RHEL-5.
Since phase 2 we'll be addressing only security and critical issues.
I'm closing this ticket as WONTFIX because this problem is neither security nor critical.

[1] https://access.redhat.com/support/policy/updates/errata/


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