CUPS: Adding printer fails with "Unable to get list of printer drivers: Success"

Question

When installing a new printer using the CUPS web interface, instead of displaying the list of drivers only the message

Unable to get list of printer drivers:
Success

is displayed. No printers can be added.

Question: What is the problem here? Searching the internet gives several reports of the problem but it is difficult to find a solution.

More information:

Also adding printers via other GUIs communicating with CUPS does not work.

Furthermore, running

lpinfo -m

prints after some time

lpinfo: success

instead of a driver list, and running

/usr/lib/cups/driver/foomatic list

takes very long time on CPU usage.

Answer 1

This bug triggers as an interaction between gutenprint, foomatic and cups.

Quick workaround:

• Remove gutenprint,
• or: Remove the package providing /usr/lib/cups/driver/foomatic (which is foomatic-db-engine on Arch Linux),
• or: Manually remove the files /usr/share/foomatic/db/source/driver/gutenprint-ijs*.xml.

More in depth:

There is an informative discussion of this problem [already here], so I provide just a summary:

• gutenprint installs two comparably big XML files, namely /usr/share/foomatic/db/source/driver/gutenprint-ijs-simplified.5.2.xml and /usr/share/foomatic/db/source/driver/gutenprint-ijs.5.2.xml (as in the current version as of this writing).
• foomatic or one of it's sub-packages (foomatic-db-engine in Arch Linux) install the perl script /usr/lib/cups/driver/foomatic.
• When CUPS tries to get a list of printer drivers, /usr/lib/cups/driver/foomatic list is called, which takes way too long time on the big XML files (this is a fault of /usr/lib/cups/driver/foomatic). Eventually, it might finish, but CUPS times out earlier without having got any information about printer drivers and produces this strange Success-error. Since it did not get information about printer drivers, it is not possible to add printers via any interface to CUPS other than manually editing configuration files.

So, as long as /usr/lib/cups/driver/foomatic is not fixed to be quicker on big files, probably the best workaround is, if one wants to have both gutenprint and a full foomatic-install, to manually remove the two big XML files provided by gutenprint. (Increasing the timeout in CUPS would not be good since one could wait for hours.)

For Arch Linux, if one builds the package locally (e.g. via the Arch Build System, or by installing with yaourt and having customizepkg set up), one can apply the following patch to the PKGBUILD of gutenprint in order to have the modification within the package:

--- PKGBUILD.old        2016-04-14 18:13:15.000000000 +0200
+++ PKGBUILD.new        2016-04-14 18:41:47.000000000 +0200
@@ -47,5 +47,8 @@
 package() {
   cd ${pkgname}-${pkgver}
   make DESTDIR=${pkgdir} install
+
+  # The following line was added by '"'customizepkg-scripting'"', script '"'$0'"', in order to work around the bug described at https://bugs.archlinux.org/task/47718
+  rm -fv "${pkgdir}"/usr/share/foomatic/db/source/driver/gutenprint-ijs*.xml
 }

Answer 2

I had this problem when trying to set up a print server on my Raspberry Pi. The only thing that seemed to work was to run this:

sudo /usr/lib/cups/daemon/cups-driverd list 1 0 requested-attributes=’ppd-make’

which I found in the comments on this article after a lot of fruitless attempts. After running that, the CUPS web UI started working as expected. I don't think I was ever using foomatic, and I was using Gutenprint.

Answer 3

I found a way to debug this problem. Cups runs lpinfo -m to get a list of printer drivers, and this runs scripts in /usr/lib/cups/driver, and one of these is causing problems. By removing all scripts and adding them one by one you can determine which script is causing the problems.

1. Move all the scripts to a subdirectory, so that they are ignored.

   cd /usr/lib/cups/driver
   mkdir disabled
   mv * disabled
   

2. Run /usr/sbin/lpinfo -m. If this runs correctly it will output a list of printer drivers. If this fails it will print "lpinfo: Success".

3. Do this for each driver: move one driver back and check whether it was the cause by running lpinfo:

   mv disabled/dymo  .
   lpinfo -m
   

4. As soon as this outputs lpinfo: Success, the last driver you moved caused the problems.

Answer 4

I also had “Unable to get list of printer drivers: Success” initially in the web interface (after some noticeable disk activity), however running lpinfo -m in command line afterwards resulted in a long list of drivers — just as it should. That was puzzling, based on the answers already given here.

But then I simply refreshed the page (that involved re-submitting the data), and the driver list was displayed successfully in WebUI, allowing me to proceed and finish adding the printer. So it may be worth to retry some time later, perhaps after checking lpinfo -m output just to be sure.