Monday, December 15, 2014

[solved] "disabled" printers in cups, "rendering complete" PT II

With an HP printer, if you click "print", but have left anything disconnected... you're going to get pissed. CUPS should simply print the job once the printer cable is reconnected. But instead of helpfully printing, CUPS is much more likely to invoke TWO horrible-to-undo factors... simultaneously.
  1. CUPS invokes a "disabled" status for the printer and does not reveal this. When you reconnect the printer, the document does not print, but the icon will only (unhelpfully) indicate "rendering complete" with a green "pause" status for the printer.
  2. You'll think, "I just need to delete the document and try again now that the cable is connected". YES, you'll have to delete the document from the queue or the problem can't be fixed. (Use lpstat -o to get the job number and then cancel [job number] to eliminate it from the queue). NO, the problem is not yet fixed, and if you try to print again, you need to delete those attempts as well. Delete all print jobs and re-enable the printer using one of the two options below.

option 1 (5 minutes)

If a person is extremely fortunate, CUPS was installed with CUPS-specific permissions and group categories aligned. There are three layers to these, the first layer being correct permissions for loopback/localhost. Users can check this by attempting to access the CUPS browser-based administration page, running out of port 631, ie, http://localhost:631/. If that works, attempt to clear the disabled printer status as follows.
  • Find your paused printer and click on it.
  • Under the "maintenance" options for that printer, click on "resume". This is what re-enables the printer.
  • Authenticate to activate changes. Typically the user is "root" and then root's password.
At this stage, printing should work again. If authentication failed, either skip to Option 2 below, or take the time* to untangle the group/member permissions (these are the second and third layers of CUPS configuration -- see "cups printer permissions" below) and then go back to the CUPS administration page, once complete.

*an entire afternoon

option 2 (15 minutes)

Remove and reinstall your printer, which hopefully is not an HP. Find your USB port for the printer (lsusb) and then, eg...
# lpadmin -x Officejet_Pro_8500_A910 $ hp-setup -i --auto 001:004
If not an HP printer, then you will likely never have this "disabled" printer problem, but if you do have to reinstall a non HP printer, then the easiest way I've found is, eg...
# lpadmin -x Brother # lpadmin -p Brother -E -v usb:/dev/usb/lp0 -m brother.ppd


  1. Cancel all print jobs. The fix might work without this, but it's unlikely. Find print job numbers using # lpstat -o and then # cancel [print number], one by one. You will see no change yet in the "rendering complete" status, but print jobs need to be cleared for the "rendering complete" status to subsequently be cleared.
  2. "resume" the printer in the CUPS browser interface (if available), or remove and reinstall the printer using the terminal. Either way, "rendering complete" should disappear at this step.
  3. Verify that CUPS changes have succeeded by attempting to print or, in a terminal, type "lpstat -p": the printer name should be there and have a status of "idle".

cups printer permissions (in progress)

Users will often only learn their CUPS configuration is misaligned when CUPS authentication fails at the final step of a long process that otherwise seemed to be successful. Any or all of the layers below can be the cause of the problem. Layer 1: loopback/localhost Sadly, CUPS is a network, not a standalone, print server. This means one must disable a percentage of their loopback protections if they want to use CUPS and the CUPS administration page. Outrageous, but true. Loopback is not dealt with on this page. Layer 2: groups
Layer 3: permissions Layer 4: /etc/cups/cups.conf (not always) Most times, nothing needs to be done to this file. When it does, the most typical adjustment involves.

No comments: