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.
Created attachment 478487 [details] suggested patch
Thanks for reporting this, and for the patch.
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
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.
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.
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.
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/