This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours
Bug 677136 - Job with multiple files gets removed after backend fails
Job with multiple files gets removed after backend fails
Status: CLOSED WONTFIX
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: cups (Show other bugs)
5.3
All Linux
unspecified Severity high
: rc
: ---
Assigned To: Tim Waugh
qe-baseos-daemons
: Patch
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2011-02-13 11:02 EST by Opher Shachar
Modified: 2013-03-11 11:23 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-03-11 11:23:29 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


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

  None (edit)
Description Opher Shachar 2011-02-13 11:02:30 EST
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 11:15:51 EST
Created attachment 478487 [details]
suggested patch
Comment 2 Tim Waugh 2011-02-14 04:49:33 EST
Thanks for reporting this, and for the patch.
Comment 3 Tim Waugh 2011-02-18 11:31:57 EST
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 Product and Program Management 2011-05-31 10:14:52 EDT
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 Product and Program Management 2012-04-02 06:33:09 EDT
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 Product and Program Management 2012-10-26 14:18:53 EDT
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 11:23:29 EDT
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.