Bug 827402 - Printing fails with Printer error: Printer "xxx" "cups-remote-pending-held"
Printing fails with Printer error: Printer "xxx" "cups-remote-pending-held"
Status: CLOSED UPSTREAM
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: cups (Show other bugs)
7.0
Unspecified Unspecified
high Severity urgent
: alpha
: 7.0
Assigned To: Tim Waugh
qe-baseos-daemons
:
: 851919 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-06-01 07:18 EDT by Martin
Modified: 2014-09-14 20:17 EDT (History)
4 users (show)

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


Attachments (Terms of Use)
Printing troubleshooter log (1.42 MB, text/plain)
2012-06-11 11:02 EDT, Martin
no flags Details


External Trackers
Tracker ID Priority Status Summary Last Updated
CUPS Bugs and Features 4125 None None None 2012-06-14 12:23:08 EDT

  None (edit)
Description Martin 2012-06-01 07:18:50 EDT
Description of problem:
Printing fails with Printer error: Printer "xxx" "cups-remote-pending-held".

Version-Release number of selected component (if applicable):
cups-1.5.3-1.1.el7.x86_64
cups-libs-1.5.3-1.1.el7.x86_64
RHEL-7.0-20120530.n.0

How reproducible:
always

Steps to Reproduce:
1. Add network printer using Control Center - Printers
2. Use "Print Test Page"
  
Actual results:
Gnome Shell notification: Printer error: Printer "xxx" "cups-remote-pending-held".
Job stays in queue in "Processing" state.

Expected results:
No error, printer should print.

Additional info:
http://wiki.brq.redhat.com/NastaveniCanon
Toner Level is updated.
Comment 1 Jiri Popelka 2012-06-04 07:01:19 EDT
Please attach an output from printing troubleshooter, thanks.
https://fedoraproject.org/wiki/Printing/Debugging#Printing_troubleshooter
Comment 2 Martin 2012-06-11 11:02:19 EDT
Created attachment 590966 [details]
Printing troubleshooter log
Comment 3 Jiri Popelka 2012-06-11 12:16:50 EDT
I can reproduce it with 1.5.3-2.fc17 while cups-1.5.2-12.fc17 is OK.
cups.brq.redhat.com runs CUPS 1.4 (RHEL-6 I guess).

Note: It's independent on what backend the server uses to communicate with the printer. It uses [1] http(ipp) as a backend to brno1-4th-cafe, but socket to brno1-1st-entrance and I see the same problem printing on brno1-1st-entrance via the cups.brq.redhat.com.

[1] http://cups.brq.redhat.com:631/printers
Comment 4 Tim Waugh 2012-06-11 12:30:43 EDT
After Create-Job succeeds, the Send-Document request fails:

D [11/Jun/2012:16:38:58 +0200] [Job 9] Send-Document: cups-upgrade-required (Upgrade Required)
E [11/Jun/2012:16:38:58 +0200] [Job 9] Unable to add document to print job.

and then it waits for the job to complete (which it won't):

D [11/Jun/2012:16:38:58 +0200] [Job 9] Set job-printer-state-message to "Unable to add document to print job.", current level=ERROR
I [11/Jun/2012:16:38:58 +0200] [Job 9] Waiting for job to complete.

cups-remote-pending-held just means the remote job is held. This is expected after Create-Job and before Send-Document, because there's nothing to print.

Seems like there are two problems here:

1. The ipp backend doesn't handle cups-upgrade-required correctly and treats it as a failure rather than retrying over a secure connection
2. The ipp backend doesn't handle Send-Document failures correctly
Comment 5 David Hladky 2012-06-12 04:09:58 EDT
I have the same problem on Ubuntu after I upgraded from 11.10 to 12.04.
Comment 6 David Hladky 2012-06-12 04:16:54 EDT
Concrete printers might help you to investigate the problem, if you have access to our RH Brno printers, so I add some details: I tried brno1-4rth-cafe and brno1-5th-cafe.

Following notification is shown:
cups-remote-pending-held

When I check the printer status on http://s01.brq.redhat.com:631/printers/brno1-4th-cafe, The print job is started, but it appears to be paused and after some time it is aborted.


The content of my cupsd.conf

LogLevel warn
MaxLogSize 0
SystemGroup lpadmin
Listen localhost:631
Listen /var/run/cups/cups.sock
Browsing On
BrowseOrder allow,deny
BrowseAllow all
BrowseLocalProtocols CUPS dnssd
BrowseAddress @LOCAL
DefaultAuthType Basic
WebInterface Yes
<Location />
  Order allow,deny
</Location>
<Location /admin>
  Order allow,deny
</Location>
<Location /admin/conf>
  AuthType Default
  Require user @SYSTEM
  Order allow,deny
</Location>
<Policy default>
  JobPrivateAccess default
  JobPrivateValues default
  SubscriptionPrivateAccess default
  SubscriptionPrivateValues default
  <Limit Create-Job Print-Job Print-URI Validate-Job>
    Order deny,allow
  </Limit>
  <Limit Send-Document Send-URI Hold-Job Release-Job Restart-Job Purge-Jobs Set-Job-Attributes Create-Job-Subscription Renew-Subscription Cancel-Subscription Get-Notifications Reprocess-Job Cancel-Current-Job Suspend-Current-Job Resume-Job Cancel-My-Jobs Close-Job CUPS-Move-Job CUPS-Get-Document>
    Require user @OWNER @SYSTEM
    Order deny,allow
  </Limit>
  <Limit CUPS-Add-Modify-Printer CUPS-Delete-Printer CUPS-Add-Modify-Class CUPS-Delete-Class CUPS-Set-Default CUPS-Get-Devices>
    AuthType Default
    Require user @SYSTEM
    Order deny,allow
  </Limit>
  <Limit Pause-Printer Resume-Printer Enable-Printer Disable-Printer Pause-Printer-After-Current-Job Hold-New-Jobs Release-Held-New-Jobs Deactivate-Printer Activate-Printer Restart-Printer Shutdown-Printer Startup-Printer Promote-Job Schedule-Job-After Cancel-Jobs CUPS-Accept-Jobs CUPS-Reject-Jobs>
    AuthType Default
    Require user @SYSTEM
    Order deny,allow
  </Limit>
  <Limit Cancel-Job CUPS-Authenticate-Job>
    Require user @OWNER @SYSTEM
    Order deny,allow
  </Limit>
  <Limit All>
    Order deny,allow
  </Limit>
</Policy>
<Policy authenticated>
  JobPrivateAccess default
  JobPrivateValues default
  SubscriptionPrivateAccess default
  SubscriptionPrivateValues default
  <Limit Create-Job Print-Job Print-URI Validate-Job>
    AuthType Default
    Order deny,allow
  </Limit>
  <Limit Send-Document Send-URI Hold-Job Release-Job Restart-Job Purge-Jobs Set-Job-Attributes Create-Job-Subscription Renew-Subscription Cancel-Subscription Get-Notifications Reprocess-Job Cancel-Current-Job Suspend-Current-Job Resume-Job Cancel-My-Jobs Close-Job CUPS-Move-Job CUPS-Get-Document>
    AuthType Default
    Require user @OWNER @SYSTEM
    Order deny,allow
  </Limit>
  <Limit CUPS-Add-Modify-Printer CUPS-Delete-Printer CUPS-Add-Modify-Class CUPS-Delete-Class CUPS-Set-Default>
    AuthType Default
    Require user @SYSTEM
    Order deny,allow
  </Limit>
  <Limit Pause-Printer Resume-Printer Enable-Printer Disable-Printer Pause-Printer-After-Current-Job Hold-New-Jobs Release-Held-New-Jobs Deactivate-Printer Activate-Printer Restart-Printer Shutdown-Printer Startup-Printer Promote-Job Schedule-Job-After Cancel-Jobs CUPS-Accept-Jobs CUPS-Reject-Jobs>
    AuthType Default
    Require user @SYSTEM
    Order deny,allow
  </Limit>
  <Limit Cancel-Job CUPS-Authenticate-Job>
    AuthType Default
    Require user @OWNER @SYSTEM
    Order deny,allow
  </Limit>
  <Limit All>
    Order deny,allow
  </Limit>
</Policy>
BrowsePoll cups.brq.redhat.com
Comment 7 Tim Waugh 2012-06-14 12:23:08 EDT
It seems that cups.brq.redhat.com only requires encryption and authentication for Send-Document, not for Get-Printer-Attributes, Validate-Job or Create-Job... or in fact, for Print-Job.

The ipp backend ought to handle this better.  Reported upstream.
Comment 8 Tim Waugh 2012-06-20 11:33:24 EDT
Note that cups.brq.redhat.com should be configured to either require authentication, or not require authentication, for Create-Job, Send-Document, and Print-Job.

In other words, all three of those operations should have the same authentication requirements.

Any changes in CUPS to support the configuration as-is will only be work-arounds for the configuration problem on the CUPS server.
Comment 9 David Hladky 2012-06-21 04:02:34 EDT
Well, in my opinion if there are several different settings, they shall be treated as several different settings. If there is the requirement to have them identical, the proper way would be to make them a single setting and not to expect they are the same. 

It worked on older systems properly so why not now?
Comment 10 Tim Waugh 2012-06-21 04:39:41 EDT
Print-Job is equivalent to Create-Job + Send-Document, so it makes no sense to have those two ways of achieving the same thing have different restrictions.

Since Create-Job is useless without Send-Document it makes no sense to have that operation any less restrictive that Send-Document.

Older systems use Print-Job, while newer systems use Create-Job + Send-Document.
Comment 14 Jiri Popelka 2012-07-23 11:21:11 EDT
Closing (not sure about the resolution) this ticket because it's been reported upstream and has no longer been bothering us (the configuration of our CUPS server has been fixed).
Comment 15 Jiri Popelka 2012-09-04 05:19:43 EDT
*** Bug 851919 has been marked as a duplicate of this bug. ***

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