[solved] CUPS "rendering completed" errors PT I

Editorial: Stand alone systems with, say, a USB printer attached, are forced to behave like a network when printing with CUPS. This faux-network process on stand-alone systems is one of looping back ("loopback") to one's system ("localhost") -- occasionally a complicated process, depending on port set-up and permissions. Added to this are network security settings since one is opening one's ports "as if" on a network. Entire books are written about this -- it's way over the head of the average user to configure ipchains, LDAP, PAM, port scramblers, and so on properly. Long story short, conflicts are nearly certain on a simple stand-alone printing setup due to CUPS negligence of stand-alone users. I hope that someday, although it's already been 20 years, CUPS developers will humble themselves and address a direct printing solution (in addition to their excellent network solution). /end rant

---

At any rate, here is a recent fail. I attempted to print a document, but forgot to attach the printer first. CUPS often provides unhelpful or misleading error messages, but no error message was generated. Rather, CUPS continued to display normal status, with a message of "rendering completed". When the printer was attached, it never printed, and no additional documents could be printed. The message that rendering was completed continued to display.

Reinstall (10 minutes)

I verified there was still a PPD in /usr/share/cups/model, located the printer using $ lsusb (in my case 001:004). then...

# lpadmin -x Officejet_Pro_8500_A910
$ hp-setup -i --auto 001:004

Partway through installation is root authentication. The printer installs perfectly and is back to printing.

A tray icon is available as well, but it uses some RAM: /usr/bin/hp-devicesettings

SystemGroup (hours and hours)

CUPS makes a simple conceptual distinction between administrator and user. SystemGroup is a category of users with system-administrator CUPS privileges. Group refers to CUPS users with printing privileges. Although simple in concept and perhaps great on a network, CUPS permissions cause suffering for stand-alone Linux users. Linux systems already isolate administrator (root) and user (user) access. Adding an additional CUPS layer is both redundant and rife with permission overlap possibilities.

First, deal with Group -- add your username to group lp in the system's group administration file, /etc/group. This is a beneficial overlap between Linux and CUPS. CUPS simply looks to see if you're in lp, and you can print.

Now, the harder category, SystemGroup. At the top of /etc/cups/cups-files.conf are the default user settings (typically lp, as just noted). At the bottom of the file are the SystemGroup settings. These are finnicky.

# nano /etc/cups/cups-files.conf
# Default user and group for filters/backends/helper programs; this cannot be
# any user or group that resolves to ID 0 for security reasons...
User daemon
Group lp

# Administrator user group, used to match @SYSTEM in cupsd.conf policy rules...
SystemGroup sys root

# Do we allow file: device URIs other than to /dev/null? [No]
FileDevice Yes

You want the CUPS SystemGroup membership to be root, so it mirrors your Linux authentications for administration. But unlike the user (lp) level, you don't want a CUPS "SystemGroup" line in your Linux system. That is, don't add a "SystemGroup" group to /etc/group; lp -yes, SystemGroup - no. The latter is CUPS specific only. Confusing.