Var log cups error log

Состояние перевода: На этой странице представлен перевод статьи CUPS/Troubleshooting. Дата последней синхронизации: 8 января 2019. Вы можете помочь синхронизировать перевод, если в английской версии произошли изменения.

В этой статье рассматриваются все неспецифические (то есть не связанные с каким-либо одним принтером) проблемы CUPS и драйверов принтеров (но не проблемы, связанные с совместным использованием принтеров), включая методы определения точной природы проблемы и решения выявленной проблемы.

Введение

Наилучший способ борьбы с неисправностями — это выставить ‘LogLevel’ в файле /etc/cups/cupsd.conf на:

LogLevel debug

А потом посмотреть вывод из файла /var/log/cups/error_log например так:

# tail -n 100 -f /var/log/cups/error_log

Символы слева от вывода означают следующее:

• D=Debug(отладка)
• E=Error(ошибка)
• I=Information(информация)
• И так далее

Следующие файлы также могут быть полезны:

• /var/log/cups/page_log — каждый раз при успешной печати, пишет новую запись
• /var/log/cups/access_log — записывает всю активность на cupsd http1.1 сервере

Также, если вы хотите решить свои проблемы, важно понимать, как вообще работает CUPS. Вот краткая информация об этом:

1. Когда вы жмёте ‘печать’ приложение отправляет .ps-файл (PostScript, язык-скрипт, который описывает, как выглядит страница) в систему CUPS (так происходит в большинстве программ).
2. CUPS смотрит на PPD-файл (файл описания принтера) и находит, фильтры которые ему нужно использовать для преобразования .ps-файла в файл, который понимает ваш принтер (например, PJL,PCL). Обычно для этого ему требуется ghostscript.
3. GhostScript принимает ввод и решает, какие фильтры ему использовать, потом применяет их и преобразовывает .ps-файл в формат, который понимает принтер.
4. Затем файл передается бэкенду. Например, если у вас принтер подключен к usb порту, то используется usb бэкенд

Распечатайте документ и посмотрите error_log, чтобы получить более подробное и правильное представление об процессе печати.

Проблемы, возникающие в результате обновлений

Проблемы возникшие после обновления CUPS и сопутствующего ему набора программ

CUPS останавливается

Существует вероятность, что для правильной работы в обновленной версии понадобится новый файл конфигурации. Например, получение сообщения «404 — page not found» при попытке входа в панель управления CUPS через localhost:631.

Для того, чтобы воспользоваться новым конфигом, скопируйте /etc/cups/cupsd.conf.default в /etc/cups/cupsd.conf (при необходимости сделайте резервную копию старого конфига) и, чтобы новые настройки вступили в силу, перезапустите CUPS.

Для всех заданий — «остановлено»

Если для всех отправленных на печать заданий установился статус «остановлено» («stopped»), — удалите принтер и установите его заново. Для этого войдите в веб-интерфейс CUPS, перейдите Принтеры > Удалить Принтер.

Для проверки настроек принтера перейдите во вкладку Принтеры, затем скопируйте отображаемую информацию. Далее нажмите на Администрирование. В выпадающем списке кликните Изменить принтер, перейдите к следующей странице(ам), и так далее.

Для всех заданий — «Принтер не отвечает»

Для сетевых принтеров, поскольку CUPS подключается через URI, необходимо убедиться, что в DNS настроен доступ к принтерам по IP. Например, если принтер подключен следующим образом:

lpd://BRN_020554/BINARY_P1

то имя хоста ‘BRN_020554’ должно соответствовать IP принтера, управляемого сервером CUPS. Если используется Avahi, убедитесь, что разрешение имени хоста Avahi работает.

Альтернативно, замените имя хоста, используемое в URI, IP-адресом принтера.

Версия PPD не совместима с gutenprint

Запустите:

# /usr/bin/cups-genppdupdate

И перезагрузите CUPS (будет выведено соответствующее сообщение после установки gutenprint).

Проблемы с сетью

Не удается найти принтер

Даже если CUPS обнаруживает сетевые принтеры, вы все равно можете получить ошибку «Не удается найти принтер» («Unable to locate printer») при попытке распечатать что-либо. Чтобы решить эту проблему, включите .разрешение локального имени хоста Avahi. Для получения дополнительной информации смотрите CUPS (Русский)#Сеть.

Эта проблема может возникать и при использовании файрвола (межсетевой экран, брандмауэр). Возможно, вам придется отключить его или установить корректные правила. Если вы используете system-config-printer для обнаружения сетевых принтеров, тогда он сделает все это автоматически.

Старый сервер CUPS

Начиная с версии CUPS 1.6, клиент по умолчанию использует IPP 2.0. Если сервер использует CUPS <= 1.5 / IPP <= 1.1, клиент не будет автоматически понижать версию протокола и, следовательно, не может связаться с сервером. Обходным путем является добавление опции version=1.1, описанной в Таблице 2. Опции URI IPP.

Общий принтер работает локально, но удаленный компьютер не печатает

Это вызвано тем, что задание на печать отправляется через фильтр дважды, один раз на локальном компьютере и один раз на удаленном. Смотрите также предупреждение на главной странице CUPS.

Не удается найти файл PPD

/var/log/cups/error_log

Cannot connect to remote printer ipp://HP079676.local
copy_model: empty PPD file

Убедитесь, что Avahi настроен правильно. В частности, проверьте, что nss-mdns установлен и настроен в /etc/nsswitch.conf.

USB-принтеры

Конфликт с SANE

Если у вас также запущен SANE, возможно, что он конфликтует с CUPS. Чтобы исправить это, создайте правило Udev, обозначающее устройство как совпадающее с libsane:

/etc/udev/rules.d/99-printer.rules

ATTRS{idVendor}=="vendor id(код производителя)", ATTRS{idProduct}=="product id(код продукта)", MODE="0664", GROUP="lp", ENV{libsane_matched}="yes"

Конфликт с usblp

Доступ к USB-принтерам можно получить двумя способами: модулем ядра usblp и libusb. Первый — это классический способ. Это просто: данные отправляются на принтер, записывая их в файл устройства в виде простого последовательного потока данных. Чтение одного и того же файла устройства позволяет использовать двунаправленный доступ, по крайней мере, для таких вещей, как считывание уровней чернил, статуса или информации о возможностях принтера (PJL). Он работает очень хорошо для простых принтеров, но для многофункциональных устройств (принтер/сканер) он не подходит, и производители, такие как HP, поставляют свои собственные бэкенды. Источник: здесь.

Важно: Начиная с cups версии 1.6.0, больше не нужно заносить в запрет загрузки модуль ядра usblp.
Если вы узнаете, что это единственный способ исправить оставшуюся проблему, сообщите об этом в баг-трекер CUPS, а также можно связаться с Till Kamppeter (сопровождающий CUPS в Debian). Для получения дополнительной информации смотрите в upstream bug.

Если у вас возникли проблемы с работой USB-принтера, вы можете попробовать запрет загрузки для модуля ядра usblp:

/etc/modprobe.d/blacklistusblp.conf

blacklist usblp

Пользователям кастомного ядра может потребоваться вручную загрузить модуль ядра usbcore, прежде чем продолжить.

После установки модулей подключите принтер и проверьте, обнаружило ли его ядро, выполнив следующие действия:

# journalctl -e

или

# dmesg

Если вы используете usblp, вывод должен указывать на то, что принтер был обнаружен следующим образом:

Feb 19 20:17:11 kernel: printer.c: usblp0: USB Bidirectional
printer dev 2 if 0 alt 0 proto 2 vid 0x04E8 pid 0x300E
Feb 19 20:17:11 kernel: usb.c: usblp driver claimed interface cfef3920
Feb 19 20:17:11 kernel: printer.c: v0.13: USB Printer Device Class driver

Если вы запретили загрузку usblp, вы увидите что-то вроде:

usb 3-2: new full speed USB device using uhci_hcd and address 3
usb 3-2: configuration #1 chosen from 1 choice

USB autosuspend

Ядро Linux автоматически приостанавливает USB-устройства, когда есть поддержка драйверов и устройства не используются. Это может сэкономить электроэнергию, но некоторые USB-принтеры считают, что они не подключены, когда ядро приостанавливает USB-порт, предотвращая печать. Это можно устранить, отключив autosuspend для конкретного устройства, для получения дополнительной информации смотрите Power management#USB autosuspend.

Плохие разрешения

Проверьте разрешения USB-порта принтера. Получите номер шины (BUSID) и устройства (DEVID) от lsusb:

 lsusb 

 Bus <BUSID> Device <DEVID>: ID <PRINTERID>:<VENDOR> Hewlett-Packard DeskJet D1360

Проверьте владельца, просмотрев devfs:

 # ls -l /dev/bus/usb/<BUSID>/<DEVID>

Демон cups запускается от пользователя «cups» и относится к группе «lp», поэтому либо этому пользователю, либо группе требуется доступ на чтение и запись в USB-устройство. Если вы считаете, что разрешения выглядят неправильно, вы можете временно изменить группу и разрешение:

# chgrp lp /dev/bus/usb/<BUSID>/<DEVID>
# chmod 664 /dev/bus/usb/<BUSID>/<DEVID>

Затем проверьте, может ли cups теперь видеть устройство USB правильно.

Чтобы сделать постоянное изменение разрешения, которое будет запускаться автоматически при каждом запуске компьютера, добавьте следующую строку.

/etc/udev/rules.d/10-local.rules

SUBSYSTEM=="usb", ATTRS{idVendor}=="<VENDOR>", ATTRS{idProduct}=="<PRINTERID>", GROUP:="lp", MODE:="0664"

После редактирования перезагрузите правила udev этой командой:

# udevadm control --reload-rules

Каждая система может отличаться, поэтому обратитесь к вики-странице udev (Русский)#Список атрибутов устройства.

Проблемы с HP

Смотрите также CUPS/Принтероспецифичные проблемы#HP.

CUPS: «/usr/lib/cups/backend/hp failed»

Убедитесь, что dbus установлен и запущен. Если ошибка повторяется, попробуйте запустить avahi-daemon.

Попробуйте добавить принтер в качестве сетевого принтера, используя протокол http:// .

Примечание: Там, возможно, потребуется установить права доступа.

CUPS: «Печать завершена», но принтер не печатает.

Это происходит на принтерах HP, когда вы выбираете (старый) драйвер hpijs (например, для Deskjet D1600 series). Вместо этого используйте драйвер hpcups.

Некоторые принтеры HP требуют, чтобы их прошивка загружалась с компьютера при каждом включении принтера. Вы можете столкнуться с этой проблемой, если есть проблема с udev (или аналогом), и правило загрузки прошивки никогда не запускается.
В качестве обходного пути вы можете вручную загрузить прошивку на принтер. Убедитесь, что принтер подключен и включен, затем выполните

hp-firmware -n

CUPS: ‘»foomatic-rip» not available/stopped with status 3’

Если, во время использования принтера HP, задания появляются в очереди, но все завершаются со статусом ‘остановлен’ (‘stopped’), а в /var/log/cups/error_log возникает одно из следующих сообщений об ошибках:

Filter "foomatic-rip" for printer printer_name not available: No such file or director

или:

PID pid (/usr/lib/cups/filter/foomatic-rip) stopped with status 3!

убедитесь, что hplip установлен.

CUPS: «Filter failed»

Ошибка «filter failed» может быть вызвана некоторым количеством причин. Журнал ошибок CUPS (по умолчанию /var/log/cups/error_log) должен записывать, какой фильтр не удалось загрузить и почему.

Отсутствует ghostscript

Установите ghostscript (/usr/lib/cups/filter/gstoraster нуждается в его запуске).

Отсутствует foomatic-db

Установите foomatic-db и foomatic-db-ppds. Это помогает в некоторых случаях.

Avahi не включен

Запустите и включите службу avahi-daemon.

Устаревший плагин

Эта ошибка может указывать на то, что плагин устарел (версия несовместима) и может произойти после обновления системы, возможно, появится сообщение Plugin error в журнале (логе).
Если вы установили hplip-plugin^AUR, вам нужно обновить пакет, иначе перезапустите hp-setup -i, чтобы установить последнюю версию плагина.

Устаревшая конфигурация принтера

Начиная с hplip-plugin^AUR версии 3.17.11 hpijs больше не доступен. Если у вас есть принтеры, использующие hpijs, они не будут печатать. Необходимо перенастроить их и выбрать вместо этого новый драйвер hpcups.

Вы можете проверить, если это ваш случай, посмотрев в error_log cups`а:

 $ grep hpijs /var/log/cups/error_log 

 ...
 D [09/Jan/2018:14:32:58 +0000] [Job 97] sh: hpijs: command not found
 ...

CUPS: печатает только пустую страницу и страницу с сообщением об ошибке на HP LaserJet

Существует ошибка, которая приводит к сбою CUPS при печати изображений на HP LaserJet (в моем случае 3380). Ошибки были зафиксированы и исправлены в Ubuntu.
Первая страница пуста, вторая страница содержит следующее сообщение об ошибке:

 ERROR:
 invalidaccess
 OFFENDING COMMAND:
 filter
 STACK:
 /SubFileDecode
 endstream
 ...

Чтобы устранить проблему, выполните следующую команду как суперпользователь (root):

# lpadmin -p printer -o pdftops-renderer-default=pdftops

HPLIP 3.13: Плагин установлен, но HP Device Manager жалуется на его отсутствие

Возможно, проблема связана с изменением прав доступа файла, которое было внесено в /var/lib/hp/hplip.state. Чтобы исправить проблему, достаточно простых команд chmod 644 /var/lib/hp/hplip.state и chmod 755 /var/lib/hp. Для получения дополнительной информации, пожалуйста, прочитайте эту ссылку.

hp-toolbox: «Unable to communicate with device»

# hp-toolbox
# error: Unable to communicate with device (code=12): hp:/usb/printer id

Разрешение проблемы

Может потребоваться добавить пользователя в группы lp и sys.

Виртуальный CDROM у принтеров

Это также может быть вызвано принтерами, такими как P1102, которые предоставляют виртуальный привод CD-ROM для драйверов MS Windows. Появляется lp dev, а затем исчезает. В этом случае попробуйте пакеты usb-modeswitch и usb-modeswitch-data, что позволяет отключить «Smart Drive» (правила udev, включенные в указанные пакеты).

Сетевые принтеры

Это также может происходить с сетевыми принтерами, использующими динамические имена хостов, если avahi-daemon не запущен. Другая причина заключается в том, что hp-setup не удалось найти принтер, потому что IP-адрес принтера изменился из-за DHCP. Если это так, подумайте о добавлении резервирования DHCP для принтера в конфигурации сервера DHCP.

hp-setup просит указать PPD-файл для обнаруженного принтера

Кроме того, при выборе файла PPD в графическом режиме hp-setup поле не обновляется и сообщение об ошибке не отображается.

Или, если вы используете интерактивный (консольный) режим, можно столкнуться с чем-то похожим на это даже при введении правильного пути к файлу ppd:

 Please enter the full filesystem path to the PPD file to use (q=quit) :/usr/share/ppd/HP/hp-deskjet_2050_j510_series.ppd.gz
 Traceback (most recent call last):
   File "/usr/bin/hp-setup", line 536, in <module>
     desc = nickname_pat.search(nickname).group(1)
 TypeError: cannot use a string pattern on a bytes-like object

Решение заключается в установке и запуске cups перед запуском hp-setup.

hp-setup: «Qt/PyQt 4 initialization failed»

Установите пакет python-pyqt4^AUR, который дополнительно требуется (optdepend) для hplip. Альтернативно вы можете запустить hp-setup с интерфейсом командной строки с помощью флага -i.

hp-setup: находит принтер автоматически, но сразу после этого сообщает «Unable to communicate with device» при печати тестовой страницы

Это, по крайней мере, происходит с hplip 3.13.5-2 у принтера HP Officejet 6500A через локальное сетевое соединение. Чтобы решить проблему, укажите IP-адрес принтера HP для hp-setup, чтобы обнаружить принтер.

hp-setup: «KeyError: ‘family-class'»

Если при добавлении принтера в пользовательском интерфейсе он не работает, или вы получили KeyError: 'family-class' от hp-setup, возможно потребуется обновить вручную /usr/share/hplip/data/models/models.dat.

Проверьте определен ли раздел family-class=Undefined для вашего принтера. Если нет, добавьте это:

/usr/share/hplip/data/models/models.dat

[hp_laserjet_pro_mfp_m225dw]	
...
family-class=Undefined

Другие

Принтер «приостановлен — «Paused»» или «Остановлен» cо статусом «Рендеринг завершен»

Низкий уровень чернил

При низком уровне чернил некоторые принтеры зависают со статусом «Рендеринг завершен» («Rendering completed»), и, если это сетевой принтер, принтер может даже стать недоступным для CUPS, несмотря на то, что он правильно подключен к сети. Замена картриджа (картриджей) с низким уровнем чернил в этом случае вернет принтер в статус «Готов» («Ready») и, если он — сетевой принтер, то он станет снова доступным для CUPS.

Примечание: Если вы используете сторонние чернильные картриджи, то принтер может сообщать неточную информацию о уровне чернил. Если вы используете сторонние картриджи, и ваш принтер работал нормально, но теперь завис со статусом «Рендеринг завершен» («Rendering completed»), замените чернильные картриджи, независимо от уровня отображаемых чернил, перед тем, как пробовать другие решения проблемы.

Завершение печати из-за ошибок авторизации

Если удаленный принтер запрашивает аутентификацию, CUPS автоматически добавит директиву AuthInfoRequired для принтера в /etc/cups/printers.conf. Однако некоторые графические приложения (например, некоторые версии LibreOffice [1]) не имеют возможности запрашивать учетные данные, поэтому печать завершилась с ошибкой.
Чтобы исправить это, укажите требуемое имя пользователя и пароль в URI.
Для получения дополнительной информации смотрите [2], [3].

Unknown supported format: application/postscript

(Не найдена поддержка формата: application/postscript)

Закомментируйте строки:

application/octet-stream        application/vnd.cups-raw        0      -

в /etc/cups/mime.convs и:

application/octet-stream

в /etc/cups/mime.types.

Ошибка задания для печати (Print-Job) client-error-document-format-not-supported

Попробуйте установить пакет foomatic и используйте драйвер foomatic.

Не удается получить список драйверов принтера

(Также применимо к ошибке «-1 не поддерживается!»)

Попробуйте удалить драйверы Foomatic или обратитесь к CUPS/Принтероспецифичные проблемы#HPLIP для обходного пути.

lp: Error — Scheduler Not Responding

Если вы получите эту ошибку, убедитесь, что CUPS запущен, переменная окружения CUPS_SERVER не установлена и /etc/cups/client.conf корректный.

Сообщение об ошибке: «Using invalid Host»

Попробуйте добавить ServerAlias * в /etc/cups/cupsd.conf.

Не удается отправить на печать из LibreOffice

Если вы можете распечатать тестовую страницу с веб-интерфейса CUPS, но не из LibreOffice, попробуйте установить пакет a2ps.

Вывод принтера сдвинут

По-видимому, это связано с неправильным размером страницы, установленным в CUPS.

Принтер не работает (приостановлен — «Paused») после ошибки

Когда во время печати возникает ошибка, принтер в CUPS может перестать отвечать на запросы. lpq сообщает, что принтер is not ready (не готов), его можно активировать с помощью cupsenable. В веб-интерфейсе CUPS принтер отображается как приостановлен — «Paused», его можно возобновить с помощью Восстановить печать.

Чтобы CUPS автоматически активировал принтер, измените политику ошибок с стандартной настройки Останавливать принтер (stop-printer) на Повторить задание (retry-this-job).

Samsung: URF ERROR — Incomplete Session by time out

Эта ошибка обычно возникает при печати файлов по сети через IPP на принтерах Samsung и решается с помощью пакета samsung-unified-driver^AUR.

Примечание: Соответствующий код ошибки 11-1112 соответствует внутренней проблеме с принтером, поэтому обращение к технической поддержке Samsung бесполезно.

Brother: Принтер печатает несколько копий

Иногда принтер печатает несколько копий документа (например, MFC-9330CDW напечатал 10 копий). Решение заключается в обновлении прошивки принтера.

Обычный пользователь не может изменять настройки принтера или удалять определенные задания

Если обычный пользователь должен иметь возможность изменять настройки принтеров или управлять очередью принтера, пользователь может быть добавлен в группу sys.

Reporting Bugs

Bugs about printing problems should be assigned to the cups package if you don’t know which package they belong to. To report printing bugs preferably use ‘ubuntu-bug cups’ from a terminal window which will gather useful information about your system related to printing like the version of Ubuntu you use, configured printers and the versions of important printing packages installed and automatically attach them to your bug report. You can also add the information after the bug is reported by executing ‘apport-collect -p cups BUGNUMBER’ where BUGNUMBER is the bug report you want to add information to.

Printer detection

NOTE: If you have a USB -> Parallel adapter, proceed as for a USB printer and also see the «USB -> Parallel adapter» section below.

USB printer

1. Make sure that the printer is connected to your system and powered on.

2. Open a terminal/console and check if the usb kernel modules are loaded:
   $ lsmod | grep usb

3. Unplug the USB printer cable from your computer and enter this command:
   $ tail -f /var/log/syslog 

4. Reconnect the USB printer cable, you should see some messages appearing.
5. Press Ctrl-C to stop the logging.

6. Check whether the printer gets correctly detected by the USB subsystem and determine its USB vendor/product IDs and the USB bus and device addresses:
   $ lsusb
   Note: The USB bus and device addresses change if you turn off or unplug the printer. Please re-run this command if needed.

7. Check whether the device files for the printer get created and the ownerships («root lp») and permissions (non-HP: «crw-rw-r—«, HP: «crw-rw-r—+») correctly set:
   $ ls -l /dev/usb/lp* /dev/bus/usb/*/*

8. Determine the printer’s device ID strings:
   $ sudo usb_printerid /dev/usb/lp0
   $ sudo usb_printerid /dev/usb/lp1
   …
   For HP printers also use
   $ hp-info -i
   and choose the printer with the problem from the text menu, then copy the «deviceid» entry from the output (can be several lines).

9. For HP printers: Check that you have the latest version of HPLIP and whether HPLIP connects to them:
   $ hp-makeuri <Bus>:<Device>
   Replace «<Bus>» and «<Device>» by the bus and device numbers from the «lsusb» output (not vendor and product ID). The numbers must be supplied with three digits, zero-padded from the left, like «008:015». (More information from http://hplipopensource.com/.)

10. Find out if your printer gets detected by CUPS:
    $ lpinfo -v

11. Attach the output of the above commands to the bug report.

Note that problems cannot only caused by CUPS but also by the kernel (package «linux»), libusb, HPLIP (package «hplip»), and several third-party printer drivers.

Parallel port printer

1. Make sure that the printer is connected to your system and powered on.

2. Open a terminal/console and check if the lp, ppdev, and parport_pc kernel modules are loaded:
   $ lsmod | grep lp
   $ lsmod | grep ppdev
   $ lsmod | grep parport_pc

3. Check if the kernel detected the parallel port during bootup:
   $ dmesg | grep par 

4. Check if the device files of the parallel port(s) are created and have the correct permissions and ownerships:
   $ ls -l /dev/lp* /dev/parport* 

5. Check if the printer auto-detection result appears in the kernel’s virtual file system:
   $ ls -l /proc/sys/dev/parport/parport*/autoprobe* 
   $ sudo cat /proc/sys/dev/parport/parport*/autoprobe* 

6. Find out if your printer gets detected by CUPS:
   $ lpinfo -v

7. Run the parallel port CUPS backend separately, once with standard user privileges and once as root:
   $ /usr/lib/cups/backend/parallel 
   $ sudo /usr/lib/cups/backend/parallel 

8. Attach the output of the above commands to the bug report.

Note that problems can be caused not only by CUPS, but also by the kernel (package «linux»), HPLIP (package «hplip»), and several third-party printer drivers.

Network printer

1. Make sure the printer is turned on and connected to your network. In the case of a WLAN (wireless) printer the printer needs to be configured to use your wireless network.

2. Check the printer’s configuration by printing a configuration page via the printer’s front panel menus. This gives information about the IP address of the printer and about the protocols it supports (JetDirect/AppSocket, LPD, IPP, SMB/Windows, …).

3. You can also find the printer’s IP address via the configuration web interface of your router. Many routers you can configure that the printer always gets the same IP and you can also assign a host name.
4. To change the printer’s configuration either use the printer’s front panel menus or the printer’s web configuration interface. To access this web interface, enter the IP address of the printer into the address or URL line of a web browser.
5. If your printer is supposed to connect via WLAN and it does not get an IP address, make sure that your WLAN is turned on and that the correct network name (SSID) and password are set by the front panel menus of the printer. If the printer has no front panel menus, you have to connct it with an ethernet cable first and configure the WLAN access through the web interface. On some HP printers there is WLAN connection but no ethernet connection. These you have to connect via USB and then use the hp-wificonfig tool from the hplip-gui package to configure them.
6. Set up the printer via system-config-printer («Add» button). Wait around 15 seconds for the network scan (spinning icon must disappear). Usually you should select the default connection type as system-config-printer tries to find the best possibility. Generally use HP printers through the HPLIP connection, other printers preferably with DNS-SD connections (will continue to work whn the router changes the IP of the printer) and from the protocols use preferably AppSocket/jetDirect. The implementation of IPP in the printer’s firmware has often bugs. Make sure the desired protocols and DNS-SD/mDNS/BonJour support are active in the printer’s hardware configuration.

7. Open a terminal/console and run the commands:
   $ ping <IP of the printer>
   $ nmap <IP of the printer>
   Replace «<IP of the printer>» by the printer’s IP address. The first command checks whether you can access the printer through the network, the second shows which port numbers are used by the printer and through this which protocols are active (80: Has web interface, 139: SMB, 443: encrypted IPP or encrypted web interface, 515: LPD, 631: IPP, 9100: JetDirect/AppSocket). Install the «nmap» package if needed.

8. Run the commands:
   $ /usr/lib/cups/backend/snmp
   $ sudo /usr/lib/cups/backend/dnssd
   The output shows whether the printers get found by CUPS or system-config-printer and with which device URIs and protocols.

9. Run the command
   $ /usr/lib/cups/backend/snmp <IP of the printer>
   if a printer does not get found by the simple «/usr/lib/cups/backend/snmp» call.

10. Find out if your printer gets detected by CUPS:
    $ lpinfo -v

11. Run the commands:
    $ avahi-browse -a -v -t -r
    $ avahi-browse -a -v -c -r
    These commands show whether your printer is visible via DNS-SD/mDNS/BonJour.

12. Run
    $ ifconfig
    $ route
    to check general network health.

13. Attach the output of the above commands to the bug report.

Note that problems cannot only caused by CUPS but also by the kernel (package «linux»), HPLIP (package «hplip»), and several third-party printer drivers.

USB -> Parallel adapter

We highly recommend not to buy and use these adapters to get old parallel-only printers connected to newer computers without parallel port. Please try the following alternatives:

1. First check whether the printer is really parallel-only. If it has a USB or Ethernet port, use one of these for connection. If you do not have free USB ports on your computer, use a USB hub.

2. If you have already a USB -> Parallel adapter and you have an All-in-One router (or NAS) with USB port, try to connect the printer with the adapter there, if the router has print server functionality, your printer should appear as a network printer.

3. You can also get an old JetDirect (or compatible) network print box on eBay or Amazon for cheap, which also makes a network printer out of your printer.

4. At least with USB -> Parallel adapters you can use with a Ubuntu machine proceeding as follows: Make sure that there is no other native USB printer or printer with USB -> Parallel adapter connected. This works only with one single printer on USB. Set up the printer with the device URI «parallel:/dev/usb/lp0», either by selecting «Enter URI» on the first page of the add-printer wizard of system-config-printer, or by right-clicking the icon of an existing (non-working) print queue, choosing «Properties» in the pop-up menu, and editing the «Device URI» field in the properties dialog. Note that you have to select printer manufacturer and model manually when adding a new printer.

Note that if the alternative you choose makes a network printer out of your printer that system-config-printer should find it as a network printer (wait for the scan to finish when the spinning icon disappears, then open the «Network printer» section). Perhaps you will need to choose make and model of the printer manually to finish the setup.

CUPS web interface

The CUPS web interface at http://127.0.0.1:631/ provides some useful messages and diagnostic capabilities.

CUPS error_log

This is a file where CUPS writes information about what it is doing. Almost all printing problems can be diagnosed from the error log, so it is the first place to look to start solving problems. To be useful, you must change the logging level:

1. In Oneiric or newer with Unity desktop click the gear icon at the upper right (the one also used to log out) and in the menu showing up then, click «Printer» (or, in some versions, «Printers»). Or go to «System Settings» in the launcher and click on «Printing». The printer setup tool system-config-printer will open. Select «Server Settings» in the list on the left or in newer versions with the printers showing as icons choose «Server» in the main menu and then «Settings». Note that the main menu will be in the bar at the top of the screen if Oneiric (or newer) with Unity is used. There it only appears if you move the mouse into the top bar. Then check the checkbox «Save debugging information for troubleshooting» and click «Apply».

2. In all Ubuntu flavors (also Kubuntu and server editions) you can run
   $ cupsctl LogLevel=debug
   to activate debug logging.

3. In Karmic and later (CUPS 1.4.x) there is an automatic debug logging only for failed print jobs. So if you problem was a failed print job, the error_log can already contain the desired information. Unfortunately, only 200 debug message lines get logged per failed job. Run the command
   $ cupsctl LogDebugHistory=999999
   for practically unlimited logging of failed jobs.

4. Clear the queue from any stuck jobs by deleting the jobs in the job viewer or running the «cancel -a» command.

5. Try to print something. Wait until the job disappears from the queue or turns into «Stopped» state, independent whether something gets out of the printer. If the job never reaches «Stopped» state after the printer not showing any reaction for a longer time you also can go on to the next step.
6. Scan or photograph the printout if it is not correct and attach the images to the bug report.

7. Add /var/log/cups/error_log as an attachment to the bug report. Note that the file is not accessible for normal users. From Jaunty on you can access it from the account of the first user set up (in general users in the «adm» group). Otherwise you need to access it as root. To view the file run
   $ sudo less /var/log/cups/error_log
   and to copy it for attaching to a bug report run
   $ sudo cp /var/log/cups/error_log ~
   $ sudo chmod 777 ~/error_log

Troubleshooting Wizard

There is a troubleshooting wizard in system-config-printer (System -> Administration -> Printing in GNOME classic, Gear icon at the upper right of the screen -> Printers in Unity). You find it in the «Help» menu of system-config-printer. It produces a text file with a lot of useful information to attach to bug reports. Follow the instructions of the wizard. If you reach the test page step, you can either click the button to print the test page or you can print a job to the selected printer from any application or from the command line. The job will be shown in the integrated job viewer. Wait until it completes or goes into «Stopped» state. ONLY THEN AND NOT BEFORE mark the checkbox at the job, answer whether the job got printed correctly, and click «Forward». After that the file will get generated. Save it and attach it to your bug report.

Print Error pop-up window

If a print job fails, a job viewer with the failed job («Stopped» state) and pop-up window telling that the job has problems will appear. If you click the «Diagnose» button, the troubleshooting wizard will open. Do not delete the job before having completed the wizard. Take care to choose the printer with which the problem occured. In the «Test Page» step you do not need to print anything, nor to wait. Mark the stopped job in the integrated job viewer, click «No» at the question and then «Forward». After that save the file and attach it to the bug report.

AppArmor Protection of the printing system

From Gutsy on the security of the CUPS printing system is improved by using AppArmor. Unfortunately, the configuration is not perfect yet, especially if third-party printer drivers are used. First make sure the apparmor-utils package is installed. If you have any problems with printing, try deactivating the AppArmor protection with sudo aa-complain cupsd. If this helps, look for messages containing audit in the /var/log/syslog file. These show which components are accessed by the printing system for which there is no explicit permission given in /etc/apparmor.d/usr.sbin.cupsd. You can re-activate AppArmor via sudo aa-enforce cupsd. Report a bug to the package cups, so that we can correct the default configuration of AppArmor.

Capturing print job data

Often it is needed to find out what actually got sent to the printer in order to determine whether the problem is caused by the application or by the printing subsystem. It is easiest to capture the job data from the application so that it can be analyzed to see whether it is already broken or not. To do so, follow these steps:

1. Clear the print queues of old jobs. Either use the job viewer or run the command
   $ cancel -a
   in a terminal window.

2. Disable the print queue with which you have the problem. Use system-config-printer (System -> Administration -> Printing in GNOME classic, Gear icon at the upper right of the screen -> Printers in Unity), right-click the appropriate printer icon, and click «Enabled» in the pop-up menu, so that the check mark disappears; or run the command
   $ cupsdisable <PRINTER>
   in a terminal window (Replace «<PRINTER>» by the name of the print queue). This makes jobs stay in the queue so that you can capture them.

3. Now print the job from your application. When the application has finished sending the job, check via the job viewer or the command
   $ lpstat -o
   whether it is in the queue.

4. Display the content of CUPS’ spool directory using the command
   $ sudo ls -1 /var/spool/cups
   (Enter your password when asked).

5. There should be exactly one file beginning with a «d». Copy this file to your home directory:
   $ sudo cp /var/spool/cups/d… ~/appout
   $ sudo chmod 777 ~/appout

6. Re-enable the print queue:
   $ cupsenable <PRINTER>
   

7. If the file gets printed correctly now, try the above procedure with another file, we need a file where the problem occurs.

8. Check via the command
   $ file ~/appout
   what format the file is. It is usually PDF or PostScript. Display the file on the screen to see whether the problem already occurs (error message, missing characters, wrong colors, …). If you see the problem already, the application is the culprit, assign your bug report to the application’s package, otherwise assign it to the «cups» package.
9. Attach the original file of your application and the ~/appout file to your bug report.

Getting the data which would go to the printer

Another important piece of data for debugging printing problems is the data which is supposed to be sent to the printer. In the previous section we captured what the application has sent to CUPS. CUPS applies several filters to this data to convert it into the printer’s native language. Here we capture the result of these filters:

1. Activate printing into a file by adding a line containing «FileDevice yes» to /etc/cups/cups-files.conf and restarting CUPS by the command
   $ sudo restart cups

2. Clone the queue of the printer with problems. The clone should print into a file and not to the actual printer, but should use the same driver, so that the same filters get applied. Use the command:
   $ lpadmin -p test -E -v file:/tmp/printout -P /etc/cups/ppd/<queue name>.ppd
   Replace «<queue name>» by the name of the queue with the problem. The clone has also exactly the same default settings as the original queue.

3. Print the job which failed to the new print queue «test». If you have selected options in the print dialog, use the same options as you used when you encountered the problem. Wait until the job finishes (disappears in the job viewer). You will have a non-empty file named /tmp/printout then. Copy this file to your home directory:
   $ sudo cp /tmp/printout ~
   $ sudo chmod 777 ~/printout

4. Attach this file to your bug report and/or examine it.

Sending a file to the printer unfiltered

If you print a file from an application or via the «lp» or «lpr» commands, the data usually goes through several filters to convert it into a format which the printer understands and to apply page management options, like 2 pages per sheet, only page 1, 3, and 9, … to it. For debugging it can be useful to bypass all these filters and let the data go directly to the printer, without any changes or conversions.

Do not send arbitrary files unfiltered to the printer now hoping that will solve any problems. Please use this mainly if you are asked for doing so in bug reports or after asking a support question.

In most cases you will have to print the data obtained from the section «Getting the data which would go to the printer» this way, often after editing it.

Use one of the following methods for unfiltered printing:

1. Independent how your printer is connected, you can print unfiltered by using the «lp» or «lpr» commands with the «-oraw» argument:
   $ lp -d <printer> -oraw <file>
   $ lpr -P <printer> -oraw <file>
   Replace <printer> by the name of your print queue and <file> by the name of the file you want to print. This does not work around bugs in CUPS backends (the modules which CUPS uses to communicate with printer hardware), see the next steps for such cases.

2. If the printer is connected via USB or parallel port, you can send the job directly to the printer’s device file:
   $ sudo -s
   # cat file > /dev/lp0
   # cat file > /dev/usb/lp0
   # cat file > /dev/usb/lp1
   # exit
   The numbers in the device file names can vary (sse also sections «USB Printer» and «Parallel port printer» above).

3. If the printer is connected via the network (both ethernet or WLAN), you can use «nc» («netcat», part of the netcat-openbsd and netcat-traditional packages, install one of them if needed) to send unfiltered data:
   $ nc -w1 <printer> 9100 < <file>
   Replace <printer> by the host name or IP address of your printer and <file> by the name of the file you want to send. If the printer refuses the job, check in the printer’s web configuration interface whether JetDirect/AppSocket/9100 printing is enabled (see also the section «Network printer» above).

PostScript (PDF) printer chokes on the PostScript (PDF) coming from Ubuntu

Unfortunately, the PostScript (or PDF) interpreters in many printers have bugs, letting them print garbage or nothing at all, or even crash/get stuck when receiving a valid PostScript (or PDF) file.

If you have a PostScript or PDF printer and it does not print correctly from Ubuntu, please report a bug and proceed as follows, telling all your results in your bug report and staying tuned for further instructions of the developers:

1. Tell us the exact Ubuntu version which you are using.
2. Tell us the exact printer model.
3. Attach the error_log, as described in the section «CUPS error_log» on this page.
4. Attach the input file which you tried to print and tell us with which application you tried to print it.
5. Attach the data which CUPS receives from the application (section «Capturing print job data» on this page).
6. Attach the data which the printer receives (section «Getting the data which would go to the printer» on this page)

7. Examine the file obtained in the previous step by running the command
   $ file printout
   

8. If the file is PostScript or PDF, subscribe «cliddell» (Chris Liddell, Ghostscript upstream developer) to the bug report and also try to display the file on the screen with «evince» and «gs».

9. Send the file unfiltered to the printer (as described in the section «Sending a file to the printer unfiltered». You should get the same problem, if you get a different (correct or incorrect) result, there is a problem with the CUPS backend (program which CUPS uses to communicate with the printer hardware).

10. If the file is PostScript, try to send uncompressed PostScript. To do so print the file obtained in step (5) with one of the commands
    $ lpr -P <printer> -o psdebug <file>
    $ lp -d <printer> -o psdebug <file>
    Repeat the steps (6) — (9) printing this way. See also the file /usr/share/doc/cups-filters/README.gz, section «POSTSCRIPT PRINTING DEBUG MODE».

11. As a workaround for the time being you can switch to an alternative program for generating the PostScript which is sent to the printer. Run
    $ lpadmin -p <printer> -o pdftops-renderer-default=pdftops
    to switch over and
    $ lpadmin -p <printer> -R pdftops-renderer-default
    to switch back. Make sure that you switch back if you follow further instructions from the developers in your bug report, or create a separate print queue for the workaround. See also the file /usr/share/doc/cups-filters/README.gz, section «POSTSCRIPT PRINTING RENDERER AND RESOLUTION SELECTION».

USB printer does not print or prints garbage

There are some USB printers who do not work when the standard communication through the USB is applied. For these exception rules need to get implemented in the USB backend of CUPS.

If your printer is connected via USB try the following steps to find out whether such exception rules could solve your problem:

1. Does your printer also allow to be connected via network? Or does your router have a USB port which can be used to make a network printer out of a USB printer? Try out these connection methods. If your printer works with them, continue with the following steps. Continue also with the following steps if you do not have possibilities to use your printer as a network printer. Otherwise, your printer has a problem which does not fall into this class.

2. Make sure your printer is connected via USB again. Run the following command in a terminal window
   $ cancel -a
   $ lpadmin -p <queue> -o usb-unidir-default=true
   with <queue> being the print queue name of the printer with problems. Now your computer does purely uni-directional USB communication with your printer. Does printing work correctly now? Run
   $ lpadmin -p <queue> -R usb-unidir-default
   to remove this change.

3. Run
   $ cancel -a
   $ lpadmin -p <queue> -o usb-no-reattach-default=true
   to make the USB backend not re-attach the usblp kernel module after the communication with the printer. Does printing work correctly for you now? Undo this change via
   $ lpadmin -p <queue> -R usb-no-reattach-default

Please report a bug on the package «cups», preferably by running the command
$ ubuntu-bug cups
Report your results of the tests above and paste in the output of the
$ lsusb
command.

Problems installing the CUPS package

Most problems of installing the CUPS package are due to the CUPS daemon not starting after the installation or update of the package and this often happens when something is not OK with the configuration settings in /etc/cups/cupsd.conf.

To find out what is happening during startup of CUPS run the following commands
$ wget http://people.canonical.com/~pitti/tmp/cups.upstart.debug
$ sudo cp /etc/init/cups.conf{,.orig} 
$ sudo cp cups.upstart.debug /etc/init/cups.conf
$ sudo stop cups
$ sudo start cups
This should fail. Please attach /tmp/log to your bug report. After that, please restore the original script again with
$ sudo mv /etc/init/cups.conf{.orig,} 

If the CUPS daemon did not start («lpstat -r» says «scheduler is not running») follow the instructions under «CUPS error_log» on this page and instead of sending a job try to start CUPS:
$ sudo /usr/sbin/cupsd
If it fails, attach your error_log to your bug report.

If you look into your /tmp/log and error_log, you can probably also already find by yourself what went wrong, for example a broken entry in /etc/cups/cupsd.conf.

To restore the default configuration file /etc/cups/cupsd.conf, run the commands:
$ sudo mv /etc/cups/cupsd.conf ~
$ apt-get download cups
$ sudo dpkg -i —force-confmiss cups_*.deb
You can also restore other configuration files, as printers.conf for example. Simply do the same steps but instead of cupsd.conf move away the offending configuration file.

Turboprint

Turboprint is a comercially distributed manufacturer-independent printer driver package. It is for photo inkjet printers, supporting several models which are not or not well supported by the drivers which come with Ubuntu (Gutenprint, HPLIP) or from the manufacturers and also adds color management with calibration service to all supported printers. You have to pay for the software and for the calibration service. You can download the software for free but after a 30-day trial period a Turboprint logo gets printed on every page.

We cannot fix bugs in Turboprint, as it is a third-party closed-source software package, like many manufacturer-supplied drivers, but the developers of Turboprint are responsive, so we can forward bug reports to them.

One known problem is that Turboprint currently ships with a Ghostscript clone based on a very old Ghostscript version, after which we have worked a lot with the original developers of Ghostscript to remove very many crash bugs. So if you have problems that certain (especially more complex) files do not print (and perhaps you find segmentation fault messages of «gszedo» in /var/log/syslog), proceed as follows:

Run the command:
$ turboprint
A window, «Turboprint Control Center» will open. Click «Preferences» at the bottom of the window. In the dialog popping up now uncheck «Use Ghostscript with extensions for Turboprint». Click «OK» in the dialog window and «Exit» in the main window.

This makes Turboprint using the current version of Ghostscript as shipped with Ubuntu, containing all the latest bug fixes.

Known bugs

Description of known issues, how to recognise them and stock responses/actions.

evince: First try to remove (or move away) the ~/.config/evince/print-settings especially if you did changes on print queues, printers, drivers, … Old settings can prevent printing (See bug 1652791). Also note that evince (and other GTK/GNOME-based applications) often generates very awkward, large PDF files which can make PostScript and PDF printers receive very large and complex files which they cannot cope with. This got improved in newer versions, but old applications, especially ones using GTK 2.x still often cause problems.

• Discuss this page

CategoryBugSquad CategoryDebugging

Translation(s): none

Techniques to deal with printing problems on the Debian CUPS based printing system.

Introduction

The aim of this page and the sections of the wiki linked from it is to give some insight on printing with CUPS in Debian 9 (stretch) and later. There are differences in CUPS between the distributions but the filtering systems are identical in principle and nearly so in practice. It is hoped that there will be sufficient detail to give an understanding of how parts of CUPS and the filtering system work and co-operate, and thereby enable effective troubleshooting.

CUPS is the manager of all printing processes via its scheduler, cupsd. It provides only a small number of filters which prepare a print job for sending to a printer:

• rastertoepson    (An Epson ESC/P and ESC/P2 filter).

• rastertohp       (A Hewlett-Packard Page Control Language filter).

• rastertolabel     (A Label printer filter).

• rastertopwg     (A CUPS raster to PWG raster filter. Very important for driverless printing).

The majority of filters needed by the Debian printing system come with the cups-filters and cups-filters-core-drivers packages. Some filters essential for Debian systems were not required by upstream CUPS, so were donated to OPenPrinting and now form the basis of the present printing system.

A selection of the filters the cups-filters packages provide is:

• pdftopdf           (A page management filter. A crucial part of the PDF-centric workflow).

• pdftops            (A PDF to PostScript filter).

• imagetopdf        (An image to PDF filter).

• gstopdf            (A Ghostscript-based PostScript to PDF filter).

• gstoraster         (A PostScript/PDF to CUPS Raster filter based on Ghostscript).

• texttopdf          (A text to PDF filter).

• brftoembosser     (A filter to support Braille embossing).

When we take the contributions of developers of other free software such as Ghostscript, Poppler, Gutenprint, qpdf and Avahi into account we can glimpse the complexity of the relationships between the components of the printing system. In spite of this complexity, the debugging methods described later can be very effective if used in a organised way.

Throughout this account CUPS is used to refer to what you get if the source is downloaded from upstream and compiled. cups-filters is an OpenPrinting project that interworks with CUPS, but responsibility for its maintenance lies with a separately developed project at OpenPrinting.

The PDF-centric Workflow

Prior to Debian 7 (wheezy), the filtering system was devised to process PostScript files; that is, anfile recognised by CUPS as a known MIME media type was first converted to PostScript before being processed. This PostScript-centric processing is now obsolete on a modern Debian printing system; PostScript hasn’t any special place in it.

At present we have a system which is designed to process files in PDF format; known MIME media types are first converted to a PDF, if necessary. This is a PDF-centric workflow.

The standard chain of filtering would first convert a submitted, known file type to a PDF. After being dealt with by the page management filter, pdftopdf, the output is further processed to produce a file acceptable to the printer, such as PostScript, PCL, Apple raster, PWG raster or some proprietary language.

File in -> convert to PDF -> pdftopdf -> PDF out -> Convert to something the printer understands -> Printer

The CUPS Error Log

The primary tool for debugging is the error log, /var/log/cups/error_log. Diagnosing printing problems is not always easy but, without the error log, it can make progress to a solution difficult. Don’t forget that not everything which is in the error_log is the responsibilty of CUPS. Errors in the filtering chain are also logged there and could be the responsibilty of programs in other packages such as cups-filters, Ghostscript, Poppler, colord, Tea4CUPS etc, all non-CUPS software. In essence, CUPS has the task of spooling and scheduling print jobs and uses the error_log to make a record of this.

Also bear in mind the error_log may shed little light on some problems and other techniques and approaches may need to be employed. There could be misconfigurations in CUPS’ files, the printer firmware or a PPD file; the input file from an application might be defective in some way; the filter chain might be suboptimal for the job.

To enable debug logging (which is sufficient for most purposes):

cupsctl --debug-logging

For all the gory detail:

cupsctl LogLevel=debug2

To turn off debug logging and return to LogLevel=warn:

cupsctl --no-debug-logging

cupsd will be restarted automatically after using any of these commands.

The file /etc/cups/cupsd.conf can also be edited by replacing LogLevel warn with LogLevel debug or LogLevel debug2. cupsd will need a manual restart if this is done:

systemctl restart cups

It is not possible to give a complete account of what to look for in an error_log because the job and the setup in the CUPS configuration files cupsd.conf and cups-files will affect its contents. The presence of error and failed should ring alarm bells but tracking down the cause may not be as easy as one would like. Handy search terms are Auto-typing and filter. Both outcomes should conform with your expectations of how a job should be processed. A glance at argv[5] is always worth it to see what options are being sent to CUPS.

Further indications of filter and backend behaviour and dispatch to a printer can be sought by searching for:

• Unloading

• Queued and queued

• JobCompleted and Job completed

• backed

• JobProgress

The error_log may be emptied by root with

>/var/log/cups/error_log

For users who rely on sudo to gain root privilege there is:

sudo truncate -s 0 /var/log/cups/error_log

An existing error_log is best emptied first before obtaining the one to be sent to a bug report. error_logs also compress very well with gzip or xz.

Capturing the File Received by CUPS

A file submitted for printing by an application or by lp/lpr first enters /var/spool/cups. If a print queue is disabled with

cupsdisable <print_queue>

it stays there and does not enter the filtering subsystem. Such a file can be identified from its date-stamp and because its name will begin with a d. The file type can determined by the file utility and should be capable of being viewed to see what the application has sent. It can also be processed with cupsfilter to emulate the expected filtering process and examine what happens at each stage.

Re-enabling the print queue gets the file printed:

cupsenable <print_queue>

If you prefer to clear out /var/spool/cups there is

cancel -a -x

Capturing the File Sent to the Printer

Any print job can be printed to a file. As root, have FileDevice Yes in /etc/cups/cups-files.conf and restart the cups service:

systemctl restart cups

Set up a print queue that prints to a file rather than sending to a printer. Either

lpadmin -p <print_queue> -v file:/tmp/out.dat -E -m (or -P) <PPD_file>

or use the web interface.

What can be done with this printer-ready file? One possibility is that it might be capable of being viewed. If it looks fine, the reason for a bad result on paper could lie with the backend used to send it to the printer or the way the printer interprets the file.

If the file cannot be viewed you could examine the previous stages which lead to its production and see whether they give acceptable outputs. If they do, you might begin to think in terms of three causes for the problem:

• The final filter.
• The backend used.
• A deficiency in the printer.

Backends and the Device URI of a Print Queue

Once the filtering system has produced a printer-ready file it is sent to the printer by a backend driver, which is really just another filter. The backend driver chosen is determined by the device-uri used when the print queue was deployed. For example,

lpadmin -p <print_queue> -v socket://<IP or hostname> -E -m <PPD_file>

would use the socket backend.

The command

/usr/sbin/lpinfo -v

lists backend devices and is very useful for discovering if a printer or printer device is detected by CUPS.

Testing a Backend and a Printer

Suppose you have a printer-ready file produced via the filtering system using cupsfilter or which has been captured before being sent to the printer. The command

lp -d <print_queue> -o raw <printer-ready_file>

will avoid the filtering system entirely and use only a backend filter before the file is passed to the printer. A record of the transaction will be in the error_log. If there is a problem with the job being printed, you can deduce it lies with the backend (usb, socket, ipp etc), the connection method (USB or ethernet cable or wireless connection) or the printer.

To rule out the backend as a cause of a problem, the printer-ready file can be sent directly to the printer.

• For a printer connected to a parallel port:

cat <printer-ready_file> > /dev/lp0

• For a USB connected printer:

cat <printer-ready_file> > /dev/usb/lp0

It would be as well to check /dev/lp0 or /dev/usb/lp0 are the correct, usable devices on your system.

• Network connected printers require a network-aware application such as netcat to process a file. Netcat doesn’t use any protocols, apart from tcp/ip. It simply shovels the data over the connection and hopes for the best.

Many network-capable printers have an open port 9100. Check with nmap:

nmap <printer_IP_or_host_name>

Then send a printer-ready file to the printer with

nc <printer_IP_or_host_name> 9100 < <printer-ready_file>

Successful printing would imply that there is a problem with the backend.

Problems Printing to a PostScript Printer

It can sometimes happen that a file sent to a PostScript printer fails in some way. For example, an error message might be produced on the first page and subsequent pages are blank. The cause is thought to lie with buggy behaviour in the printer’s PostScript interpreter even when given valid PostScript.

The filtering chain might be

  PDF file -> pdftopdf -> pdftops -> PostScript -> printer

The pdftops filter has the option to convert the PDF into PostScript using Ghostscript, Poppler, Cairo, Adobe Reader or Mupdf. The default mode is one which uses Poppler when the printer make is Brother, Minolta or Konica Minolta but Ghostscript for other printer models. If there is a problem with one of these other models it may be beneficial to switch to rendering PostScript from the PDF with the pdftops-renderer option. Details are in /usr/share/doc/cups-filters/README.txt.gz. See also POSTSCRIPT PRINTING DEBUG MODE in the same document. To use Cairo as the renderer:

lpadmin -p <print_queue> -o pdftops-renderer-default=pdftocairo   (For an existing queue).
lp o pdftops-renderer=pdftocairo <print_job>  (On a job-to-job basis).

Problems Printing to a USB Connected Printer

A USB problem can be difficult to track down. The USB backend uses libusb and there is the possibility of a bug in that software. USB to parallel adapters do not always give trouble-free operation. Also, it is not entirely unknown for printers to have bugs in their implementation of the USB standard and, indeed, CUPS has quirks rules to deal with such issues. Options to handle some USB problems have been added to CUPS. Here is an account and analysis of a printing problem solved by the application of a USB quirk.

• Obtain the USB device-uri for the printer and set up a print queue with lpadmin. Finding the device-uri will act as a test of the connection between computer and printer.

• Forcing the usb backend into unidirectional mode can work round problems with bidirectional communication. Preventing the reattachment of the usblp kernel module after a job has been printed can prevent some printers cutting off the end of a job or crashing.
• To have only unidirectional USB communication with the printer the print queue should be set up with

lpadmin -p <print_queue> -v <deviceuri> -o usb-unidir-default=true -E -m <PPD_file>   (For a new queue).
lpadmin -p <print_queue> -o usb-unidir-default=true   (For an existing queue).
lpadmin -p <print_queue> -R usb-unidir-default        (Remove default).

• To not reattach the usblp kernel module after communication with the printer the print queue should be set up with

lpadmin -p <print_queue> -v <device-uri> -o usb-no-reattach-default=true -E -m <PPD_file>   (For a new queue).
lpadmin -p <print_queue> -o usb-no-reattach-default=true   (For an existing queue).
lpadmin -p <print_queue> -R usb-no-reattach-default        (Remove default).

Problems Printing to a Network Connected Printer

It is not uncommon for a printer to be connected over the network to a CUPS server, particularly when it is a legacy/classic device.| The server receives the print job from a client, processes it, usually using vendor drivers, and sends it off to the printer. A modern device is directly contactable, so the need for such a network printer might be seen as superfluous in that case.

A network printer is a printer device with its own TCP/IP port at 631, 9100 or 515, connected to the network by ethernet cable or wireless and used in conjunction with a CUPS server. The printer receives jobs in the usual way from the CUPS server.

+---------+    Ethernet cable    +---------+     +--------+
|         |<-------------------->|         |<--->|        |
| Printer |                      | Network |     | Server |
|         |<====================>|         |<===>|        |
+---------+      Wireless        +---------+     +--------+

• It is assumed the printer is already on the network with a DHCP assigned or a static IP address. The printer manual should be consulted to ascertain how to set up an ethernet cabled or wireless connection.

• It is further assumed that security software on any client device, for example, a firewall, SELinux or AppArmor, does not interfere with the printing or network processes.

• Two other assumptions are that a default CUPS installation is installed on the server machine with the cups package and that an examination of its filtering system as described previously on this page has returned nothing of consequence.

• The IP address of the printer can often be found from its front panel or from a printed configuration (self-test) page. Running the snmp backend on the server is a quick alternative. The output should include the device-uri of the device (which is likely to be a socket connection).

/usr/lib/cups/backend/snmp

• Now the ping utilty can be used. With consistent output you should be confident the printing system should be able to locate the printer. Inconsistencies such as many dropped packets or high latency could mean looking at the network setup. Check for the IP address changing on a regular basis or something blocking the ICMP probes.

ping <IP_address_or_hostname>

• The printer can be scanned with nmap to discover the printing services it offers. Look for ports 515, 631 or 9100 being open. Not all printers offer the same services. An open port 80 would indicate an embedded web server (EWS), a very useful facility for making alterations to the printer’s configuration with a browser.

nmap <IP_address_or_hostname>

The following netcat command tests whether the printer can be reached on port 631:

nc -z <IP_address_or_hostname> 631 && echo ok || echo failed

If the printer cannot be reached, it may be switched off or not have a service on port 631 or there is some basic network problem

• The choice of device-uri may be a factor in the quality of the printing experience. A diagnosed problem with the printer implementation of IPP can be tackled by preferring the socket backend; a failure now with printing could point to a network or printer issue, especially as all that is being done is send raw data over TCP/IP to the printer.

• A printer which does Bonjour broadcasting can be discovered and identified using avahi-browse:

avahi-browse -rt _ipp._tcp

address =, port = and rp= give its IP address, the services it offers and the resource part of an IPP device-uri respectively. If you have a printer which fits a client’s driverless printing system

driverless

will give you the hostname and IPP device-uri for the printer.

Problems with mdns/DNS-SD

Discovery of mDNS (Bonjour) shared printers and print queues takes place by default when avahi-daemon is installed. Applications will list these printers and queues in their dialogs. Browsing for mdns/DNS-SD advertised printing services can be done with avahi-browse or its GUI equivalent, avahi-discover.

avahi-browse -rt _ipp._tcp

It is possible for all the queue filters to operate correctly and for the backend to behave impeccably but nothing gets printed. One cause is a firewall misconfiguration. Check with

iptables --table filter --list | grep mdns

and check the avahi-browse output. Failed to resolve service and an address line which is not in the form xxx.xxx.xxx.xxx would be indications of such a misconfiguration.

A failure to get the print job to a remote printer might also be a router or network problem.

See Also

• The Debian Printing Portal

CategoryPrinter

200

Successful operation.

201

File created/modified successfully.

304

The requested file has not changed.

400

Bad HTTP request; typically this means that you have a malicious program trying to access your server.

401

Unauthorized, authentication (username + password) is required.

403

Access is forbidden; typically this means that a client tried to access a file or resource they do not have permission to access.

404

The file or resource does not exist.

405

URL access method is not allowed; typically this means you have a web browser using your server as a proxy.

413

Request too large; typically this means that a client tried to print a file larger than the MaxRequestSize allows.

426

Upgrading to TLS-encrypted connection.

500

Server error; typically this happens when the server is unable to open/create a file — consult the error_log file for details.

501

The client requested encryption but encryption support is not enabled/compiled in.

505

HTTP version number not supported; typically this means that you have a malicious program trying to access your server.

Foreword

If you are experiencing a problem with printing, please take a look at the common bugs page before filing a bug. If the problem you are seeing is not listed there or none of the workarounds seem to help, please consider filing a bug report to help us make Fedora run better on your hardware.

Identifying your problem area

Printing issues can be fairly complex and active cooperation or lots of data can be requested from reporter by maintainer to helping maintainer to at least understand and (if it is not hardware specific issue) reproduce the issue, so please have a patience and try to narrow the problem as much you are able to for maintainers.

There can be:

• issues with seeing or connecting to the printer (it can be cups backend issues, avahi issues, libusb issues, cups-browsed issues),
• accessibility issues (correct/wrong setup in cupsd.conf or its bad interpretation by cupsd daemon, bad cooperation with NIS, SSSD…),
• printing with help of samba (issues with smb backend, which is part of samba) or with samba authenticated through Kerberos (samba_krb5_printing),
• issues with filters used during filtering the document into document format supported by printer, which influence how or if the document will be printed (issue with filters — pdftops, pdftopdf, pstops, bannertopdf etc. — or issues with binaries or libraries which filters uses — libgs, qpdf, poppler…),
• issues with Postscript Printer Description files, which are old way of defining printers capabilities like supported page sizes, borders etc…

Not mentioning possible limitations or issues in firmware or hardware of printer itself, so any kind of data or narrowing the issue is welcomed.

The best start is to attach files with logs described further down.

CUPS logging

All CUPS logging is redirected to journal by default since Fedora 28 (there was a redirecting of error_log to journal by default before Fedora 28, since Fedora 20). Printing troubleshooter doesn’t have a feature to get logs from systemd journal yet, so CUPS logs need to be acquired by following steps.

We need to define two different ways of capturing incident-bound CUPS whole logs — the one if the broken print queue isn’t provided by HPLIP and the other if it is. They differs in the filter option of journald — if you use non-HPLIP queue for debugging, it is okay to gather the logs from cups systemd unit (by ‘-u cups’), because all error messages are correctly redirected to cups systemd unit logging and they are accessible in the output after unit filtering. HPLIP libraries are not implemented to do the same (upstream is unresponsive to accept a potencial fix into the project and the issue is not critical enough to drag a downstream patch forever), so their messages aren’t marked for cups systemd unit and they’re filtered out after calling journald with ‘-u cups’. For such queues journald log without filtering is required.

Note:

Incident-bound journald log without filtering is required only for HPLIP print queues (their device uri starts with hp://) and it is unwanted for other queues, because it can be hard to read in larger cases. Please attach incident-bound journald log only when it is necessary.

Location of CUPS logging

CUPS logging is located in the system journal by default, but the logging into a file can be set in /etc/cups/cups-files.conf with directive ‘ErrorLog’. If you want to change the default settings, then the name of the logging file is irrelevant, but it is recommended to put the file into path ‘/var/log/cups’, otherwise SELinux will block cupsd from accessing it.

Setting the logging to a file has following cons (without further operations):

• unable to get only logs connected to a job without chaining more commands
• unable to get logs for specified time frame without chaining more commands

For capturing a incident-bound logs ‘tail -f’ can be used e.g.:

tail -f /var/log/cups/error_log

Enable CUPS debug logging

Enable full debugging information with:

sudo sed -i 's,LogLevel warn,LogLevel debug2,' /etc/cups/cupsd.conf

CUPS job log

IMPORTANT If the problem appears when you sent document to print or if you are trying to, capture logs for this job. If the job log is available, its attaching is REQUIRED.

Prepare CUPS for job logging

For being able to see specific job log, please turn on:

PreserveJobFiles Yes

in your /etc/cups/cupsd.conf file and restart cup service. Do not forget to remove the line after you are done with debugging. ‘lpstat -W all’ seems to be empty after printing if you do not enable the directive.

Get a job log for a specific Job ID

To capture job log you need to know Job ID (JID) of the job — it is a number which together with print queue name specifies the job as request ID — for getting logs specific for the job.

Job ID can be seen in terminal if you send a document to print by lp command:

$ lp -d <print_queue_name> <file1> ... <fileN>
request id is <print_queue_name>-<JID> (N file(s))

Or when you list jobs (see man lpstat) — the latest job is at the end:

$ lpstat -W all
...
<print_queue_name>-<JID>           <user>           1024   Wed 11 Jan 2017 05:52:19 PM CET

You can get the latest job logs automatically (if you have awk installed and lpstat -W all returns jobs) by:

$ journalctl -u cups JID=`lpstat -W all | awk '{print $1}' | awk -F '-' '{print $NF}' | tail -n 1` > cups_job_log

Or manually, if you found JID by yourself:

journalctl -u cups JID=<JID> > cups_job_log

Incident-bound cupsd log (broken print queue isn’t HPLIP supported)

Sometimes we cannot bind the error with a specific print job, so the job log is uneffective. Incident-bound cupsd log is needed.

How to start to capture incident-bound cupsd logging

In new terminal/terminal tab, please issue:

journalctl -f -u cups > cups_whole_log

How to get incident-bound cupsd logging

After you trigger the error condition you are trying to diagnose e.g. printing something, try to find a printer via lpinfo etc., you terminate capturing incident-bound cupsd log from step above by ctrl+c.

Incident-bound cupsd log (broken print queue is HPLIP supported)

Unfortunately, HPLIP libraries don’t log into CUPS unit in journal, so if your print queue is installed with HPLIP driver (its device uri starts with hp://), we need incident-bound journal log.

How to start to capture incident-bound journal logging

In new terminal/terminal tab, please issue:

journalctl -f > journal_whole_log

How to get incident-bound journal logging

After you trigger the error condition you are trying to diagnose e.g. printing something, running HP script etc., you terminate capturing incident-bound journal log from step above by ctrl+c.

Turning off debug logging

Please attach cups_job_log for the problematic job, cups_whole_log or journal_log if you caught whole cupsd log during the problematic event to bug report as an attachment.

Then to turn off debugging information, do this:

sudo sed -i 's,LogLevel debug2,LogLevel warn,' /etc/cups/cupsd.conf

More commands for working with systemd-journald

View the log messages with:

journalctl -u cups -e

or:

journalctl -u cups --since=...

To filter out messages relating to a specific job ID, use:

journalctl -u cups JID=...

(tab completion will show you which job IDs have log messages)

cups-browsed logging

cups-browsed daemon was introduced in Fedora around cups-1.5 version. It can browse Bonjour broadcasts, CUPS broadcasts (deprecated) and LDAP servers for printers and create or remove local queues pointing to those printers. It can creates broadcasts of local CUPS queues, but it is marked as deprecated.

For setting debug logging on you need to add:

DebugLogging stderr

to /etc/cups/cups-browsed.conf.

The logs will be available in system journal after cups-browsed restart.

HPLIP scripts debug logging

Python scripts from HPLIP (e.g. hp-setup, hp-clean, hp-scan) have debug logging redirected to the standard error file descriptor, so they are not logged in journal. For getting their debug logging, run the script with -ldebug parameter e.g.:

$ hp-setup -ldebug -i

and reproduce the issue. Then copy the messages from terminal into hp_script_log. Please attach the file to the bugzilla ticket too.

What make and model is my printer?

Each different printer has a model-specific Device ID. You can find out with the lpinfo command:

lpinfo -l -v

This command runs each of the backends in discovery mode, to get them to report devices they can automatically detect. This will output a series of blocks of lines, each one like this:

Device: uri = usb://HP/DESKJET%20990C?serial=U123456789AB
        class = direct
        info = HP DESKJET 990C
        make-and-model = HP DESKJET 990C
        device-id = MFG:HEWLETT-PACKARD;MDL:DESKJET 990C;CMD:MLC,PCL,PML;CLS:PRI
NTER;DES:Hewlett-Packard DeskJet 990C;SN:U123456789AB;S:00808880800010032C100000
0C2000000;P:0800,FL,B0;J:                    ;
        location = 

The line which identifies this particular model type is the long one that starts «device-id =» (shown here wrapping over three lines).

Note that if your printer cannot be automatically detected, you may still be able to find out the Device ID by running the appropriate backend with the printer hostname as the argument. The usb, parallel, snmp, and dnssd backends all try to report the actual Device ID given by the printer.

$ /usr/lib/cups/backend/snmp 10.34.18.3

network socket://10.34.18.3 "HP Color LaserJet CP2025dn" "HP Color LaserJet CP2025dn"
"MFG:Hewlett-Packard;CMD:PJL,PML,PCLXL,POSTSCRIPT,PCL;MDL:HP Color LaserJet CP2025dn;
CLS:PRINTER;DES:Hewlett-Packard Color LaserJet CP2025dn;MEM:MEM=55MB;COMMENT:RES=600x8;" "HP Color LaserJet CP2025dn" 

Device ID is in this case (see backend(7)) the last but one field.

Which print queues are available for me?

The queues on your machine can be permanent ones or temporary. CUPS is capable to list all available print queues on the local network (permanent and temporary queues) by:

$ lpstat -e

For permanent queues you are able to get more info with:

$ lpstat -t

Which driver am I using?

The PPD file for the printer queue can tell you which driver is in use. You can use this command to find out which driver is being used:

grep -H '^*NickName:' /etc/cups/ppd/*.ppd

You can also find this out using the system-config-printer application. Double-click on the icon for the queue and look at the Make and Model field.

To see the available drivers, click on the Change… button next to that field. You might find it useful to try another driver to see if that shows the same problem.

Driverless models

Most printers released since 2010 are capable of AirPrint or IPP Everywhere, which means they don’t need to be installed to work — the device is found by Avahi and the print capabilities are communicated via IPP protocol — they are basically driverless devices. There are two solutions in Fedora which implement IPP everywhere:

• CUPS ‘everywhere’ model
• cups-filters ‘driverless’ driver

CUPS ‘everywhere’ model

It is CUPS implementation of IPP everywhere standard, available as a special printer model. The model is used when you use CUPS temporary queue for your device or if you install your device with as IPP Everywhere model in CUPS web ui or via lpadmin (using -m everywhere).

Because the created PPD file depends on IPP communication with printer, we need info which is gathered from the device. You can use ipptool for that:

$ ipptool -tv <your_printer_device_uri> get-printer-attributes.test &> ipptool_log

Attach the created ipptool_log to the bugzilla ticket if needed.

cups-filters ‘driverless’ driver

Cups-filters special driver which is used for generating PPD according IPP Everywhere standard. The driver is used if you choose driverless model during printer installation.

We need get-printer-attributes request output too:

$ ipptool -tv <your_printer_device_uri> get-printer-attributes.test &> ipptool_log

and debug logs from the driver itself when it generates PPD for your device:

$ driverless -d cat <ipp_device_uri> 2> driverless_debug > created_ppd

Attach all created files to the bugzilla ticket if needed.

Finding where the problem lies

When a print job is processed it is sent through a chain of filters to convert the file into a format the printer can understand, and then finally sent to a backend, a program which can transport the data to the printer. By slightly changing how you print you can try a different printing path to see if that changes anything. If it works around the problem, you know which area the problem was in — include that information in a bug report so that we can fix it.

Application

Try printing from a different application to see if the problem goes away or if it occurs regardless of how a file is printed. Try printing the document from the command line using the lp command.

Document format

If you are having problems printing PDF files, try printing other types of file to see if the problem is with printing anything or if it is specific to printing PDF files. Try converting the file to a different format and printing that.

If the problem relates to printing text files, try removing/installing the paps package. This package provides an alternative text-to-PostScript filter to the one that comes with CUPS.

To inspect the document that was submitted to CUPS for printing, enable the PreserveJobFiles option like this:

cupsctl PreserveJobFiles=yes

Submitted job documents will remain in /var/spool/cups. There are files with two types of names — dXXXXX-YYY and cXXXXX. dXXXXX-YYY is file which goes to CUPS system, unfiltered file — XXXXX is job ID, which is filled with zeros to be 5 characters long, and YYY is sequence number of file in the job. cXXXXX is file which contains printing options for a job specified by job ID in XXXXX. Please attach dXXXXX-YYY to the bug for a job when you experience the issue

Running filters by hand

More advanced users may like to try running the CUPS filters by hand and examining the data file at each step as it is converted between different formats. Here is an example of doing this for a gutenprint queue named pqueue with the CUPS test page which is its own special MIME type, application/vnd.cups-banner:

First you need to know the filter pipeline for application/vnd.cups-banner —> printer/pqueue (output MIME type).
You can either enable debugging, print a test page, look into /var/log/cups/error_log and you’ll find something similar to:

envp[29]="FINAL_CONTENT_TYPE=printer/pqueue"
Started filter /usr/lib/cups/filter/bannertopdf (PID 1111)
Started filter /usr/lib/cups/filter/pdftopdf (PID 1112)
Started filter /usr/lib/cups/filter/gstoraster (PID 1113)
Started filter /usr/lib/cups/filter/rastertogutenprint.5.2 (PID 1114)

or run

/usr/lib/cups/filter/bannertopdf 1 me '' 1 '' </usr/share/cups/data/testprint >bannertopdf.pdf
cupsfilter -e -m printer/pqueue -p /etc/cups/ppd/pqueue.ppd bannertopdf.pdf > /dev/null

and you’ll see:

INFO: pdftopdf (PID 1111) started.
INFO: gstoraster (PID 1112) started.
INFO: rastertogutenprint.5.2 (PID 1113) started.

Now you can run filters by hand:

export PPD=/etc/cups/ppd/pqueue.ppd
/usr/lib/cups/filter/bannertopdf 1 me '' 1 '' </usr/share/cups/data/testprint >bannertopdf.pdf
/usr/lib/cups/filter/pdftopdf 1 me '' 1 '' <bannertopdf.pdf >pdftopdf.pdf
/usr/lib/cups/filter/pdftoraster 1 me '' 1 ''<pdftopdf.pdf >out.ras
/usr/lib/cups/filter/rastertogutenprint.5.2 1 me '' 1 ''<out.ras >out.prn

Here, evince or okular can be used to examine the output after the first two filters, rasterview can be used to examine the output of the third filter, and the last filter’s output must be inspected by hand or sent directly (lpr -oraw out.prn) to the printer.

Driver

If you have access to a different make/model of printer it might be worth trying to see if the problem occurs on both of them or just one. This can give an indication about whether it is a problem with a particular driver, or if it is a more general problem.

Even if you only have access to the one printer there is often a choice of drivers to use for a given printer model, and trying each one in turn can be useful in narrowing down the problem. See above for how to do that.

Foomatic

For Foomatic drivers you can try enabling Foomatic debugging by editing the file /etc/foomatic/filter.conf and adding a line:

debug: 1

Next time you print a job to a queue using foomatic the debugging will be put in /tmp/foomatic-rip.log, and the input file as received by foomatic-rip will be in /tmp/foomatic-rip.ps.

Backend (job transport)

It may be possible for you to try a different backend. Using system-config-printer, double-click on the printer queue icon and click the Change… button next to the Device URI field. You may see a Connection expander arrow near the bottom right hand corner of the window — click that to see which backends are available. For USB-connected HP printers, typically either of the hp and usb backends can be used.

For capturing USB communication:

• find out the bus number where USB device is connected, f.e.:

$ lsusb
Bus 002 Device 010: ID 03f0:012a HP, Inc HP LaserJet M1536dnf MFP
      =

• start USB packet capture:

$ sudo tcpdump -i usbmonN -s0 -w usb.pcap

where N is the bus number.

For network printers you may have different protocols you can try.

• socket is for HP JetDirect (usually port 9100)
• lpd is for older style UNIX print shares
• smb is for CIFS shares from Windows systems
• ipp is for Internet Printing Protocol-enabled devices and also for other CUPS servers
  • You can capture the IPP traffic with tcpdump like this (the interface name may differ from p4p1):

 tcpdump -n -i p4p1 -U -s0 -w ipp.pcap port ipp

• bjnp is for Canon’s proprietary bjnp network protocol (usually port 8611)

Configuration tool

If your problem relates to configuring print queues, try using one of the other methods of doing so. There are four available:

• The GNOME 3 System Settings application (control-center), System Settings > Printers from the GNOME Shell
• system-config-printer, System > Administration > Printing from the GNOME menu
• the CUPS web interface, http://localhost:631/
• the command line tools lpadmin, lpoptions, cupsctl, cupsaccept, cupsenable etc.

User stories

There are several common user stories when it comes to debugging printing issues. I’ll mention some of them with steps how to get necessary information.

I have HP printer and have a problem with HPLIP script

Please follow the steps in the following sections:

• enable CUPS debug logging
• start to capture journal logs
• run the script with enabled debugging
• get the journal logs
• attach the files to the bugzilla ticket and turn off debug logging
• provide printer model name and printer PPD file from /etc/cups/ppd/

I have HP printer, installed it with HPLIP and have a problem with it

HPLIP installed print queue has a device uri starting with hp://.

Please follow the steps in the following sections:

• enable CUPS debug logging
• start to capture journal logs
• trigger your issue
• get the journal logs
• attach the requested files to the bugzilla ticket and turn off debug logging
• provide printer model name and printer PPD file from /etc/cups/ppd/

My printer doesn’t print correctly or at all, but I can see the printer in print dialog

Please follow the steps in the following sections:

• enable CUPS debug logging
• prepare CUPS for job logging
• restart CUPS service
• trigger your issue — print the specific document to the specific print queue you have problem with
• get the job log for the job you have just triggered
• attach the created files to the ticket and turn off debugging
• attach your printer PPD file from /etc/cups/ppd/ if available
• attach the file you wanted to print
• tell what application you printed from
• mention your printer model

CUPS generic issue

For generic issues — printer wasn’t found, segfault — please follow the steps in the following sections (avahi-daemon must run):

• enable CUPS debug logging
• start to capture logs
• trigger the issue — e.g. try to find printers via sudo lpinfo -l -v, do some action in web ui — depends on your problem
• get the logs
• attach created files to the ticket and turn off debugging
• put the output of lpinfo into a file and attach it
• put the output of both lpstat commands into a file and attach it

My printer doesn’t print correctly — I use ‘everywhere’ model

Please follow the steps in the following sections:

• get data from get-printer-attributes request
• follow the steps with CUPS job log user story

I have a generic problem with cups-browsed

Please follow the steps in the following sections:

• enable CUPS debug logging
• enable cups-browsed logging, but don’t restart cups-browsed yet.
• start to capture cupsd logs
• start cups-browsed via systemctl and start to capture its logs:

$ journalctl -u cups-browsed -f > cups_browsed_log

• trigger the issue or wait until cups-browsed triggers the issue itself
• cancel cups-browsed and cupsd log captures
• attach created files cups_whole_log and cups_browsed_log to the ticket and turn off debugging

Printer found by cups-browsed doesn’t print or print badly

The most difficult user story — we need to know how the print queue was created and how it behaves during printing. The print queue found by cups-browsed has a device uri starting with implicitclass://.

Please follow the steps:

• get printer info from get-printer-attributes and PPD file
• enable CUPS debug logging
• enable cups-browsed logging, but don’t restart cups-browsed yet.
• start to capture cupsd logs
• start cups-browsed via systemctl and start to capture its logs:

$ journalctl -u cups-browsed -f > cups_browsed_queue_creation

• give cups-browsed some time to process found devices (depends on how many devices you have in the local network or how many print queues are stored in the location you set with BrowsePoll directive)
• cancel cups-browsed and cupsd log captures — save the files as cups_queue_creation and cups_browsed_queue_creation

Now we need to capture the logs during printing:

• prepare CUPS for job logging
• restart CUPS service
• start to capture cups_browsed logs again:

$ journalctl -u cups-browsed -f > cups_browsed_printing

• trigger your issue — print the specific document to the specific print queue you have problem with
• get the job log for the job you have just triggered and cancel the capture of cups-browsed logging
• attach all gathered log files

Filing a bug report

Deciding which component

Problems involving printing may relate to several components.

The configuration GUI (See above) is either GNOME 3 System Settings application or system-config-printer. These packages also provide the printer applet, handle automatic queue creation, and disable/enable queues when USB printers are disconnected and reconnected.

Most GTK+ applications use the GTK+ print dialog. If the problem occurs when using GTK+ applications but not when printing from the command line or from another non-GTK+ application, the problem should probably be reported against gtk2. If the problem occurs with only one GTK+ application, and other GTK+ applications print fine, the bug should be filed against that particular application.

If the problem only happens with PDF files, the bug may well be in poppler (the CUPS pdftops filter is a wrapper around one of the poppler utility programs).

Report bugs only seen using the smb backend against samba.

For bugs only seen when using the hp backend, or the hpijs or hpcups drivers, select hplip for the component.

For bugs for cups-browsed daemon and its printer discovery, please select cups-filters

Other possibilities, depending on the problem, include:

• foomatic (the Foomatic CUPS filter and driver)
• foomatic-db (the actual printer database used by Foomatic)
• ghostscript (which converts PostScript to other formats)
• gutenprint (a driver that supports very many printers)

For anything else, or if you are not sure, choose cups or use your best guess.

Other information to include

Be prepared to include some information about your system as well. Some of this can be gathered automatically using the printing troubleshooter, but you may also need to include other information.

Before gathering of information

• Please change your OS locale to English. Manual [1].
• Please attach gathered information as archive (example is here, you may need root permissions) to the bugzilla issue.
• Please do not forget to trigger your issue after debug enabling and restarting cups and before information gathering.

Information to gather

• the PPD file for the print queue (from the /etc/cups/ppd directory)
• the document you are attempting to print — if the document is large, please try to see if the problem also occurs with a smaller document
• cupsd journal logs when debug level 2 is turned on. How-to for turning debug2 on and for getting logs from systemd-journald is above.
• if the issue is connected to a print job, attach journal logs for this specific job too. How-to get logs here, example with JID. You can find out JID value by command:

$ lpstat -W all

. Find your job there and JID is a number after ‘-‘.

• If the issue is about f.e. ‘printing from evince prints garbage, but printing from libreoffice works’, then attach two separate files — first will contain logs when you print from evince, latter logs when you print from libreoffice.
• troubleshoot.txt from system-config-printer (BEWARE: it doesn’t contain journal logs — don’t forget to attach them too).
• make and model of printer
• config files — /etc/cups/client.conf (if it contains any changes from default), /etc/cups/cupsd.conf
• if the issue is with cups-browsed and printer’s discovery, attach /etc/cups/cups-browsed.conf and cups-browsed logs gained by how-to above.

Some example documents can be found in the Printing Test Cases category.

Further reading

The main printing page has more information about how printing works in Fedora.

How to debug scanning issues

SANE library, communication libraries and backends can turn on and off debug logging via SANE_DEBUG_* environment variables.

The common environment variables:

• SANE_DEBUG_DLL — enables debugging SANE library
• SANE_DEBUG_SANEI_USB — enables debugging communication library for USB — add the environment variable if your device is connected via USB cable
• SANE_DEBUG_SANEI_TCP — enables debugging communication library for wireless/ethernet — add the environment variable if your device is connected by Wifi or Ethernet

Environment variables for enabling debugging a specific backends have a structure — SANE_DEBUG_<backend_name>, so the environment variable for f.e. HPAIO backend is SANE_DEBUG_HPAIO.

You can find which SANE backend supports your device here. If your device is HP and it isn’t supported by airscan backend or any other SANE backend, it can be supported by hpaio backend from hplip package, see the list of supported devices here.

Before you start debugging

The acquired log files can be quite big in case you use high resolution, do colored scanning, use higher scanning steps etc., so it would be great if you checked whether your issue happens:

• with the lowest scanning step
• with the lowest resolution
• in Lineart mode
• with .pnm as output file format

If the issue happens even with the lowest settings, do use these settings during debugging steps below.

Debugging scanner discovery

If you don’t see your scanner in scanning application, then debugging of discovery process is in order. I prefer using scanimage in the examples, but the similar steps can be applied for every scanning application like xsane, scanadf, simple-scan etc.

You will need to use environment variables when you start a scanning application (scanimage in this case). The environment variables used with scanimage command depends on how your scanner is connected and which backend suppose to support it. So for getting debug logs there is a skeleton:

$ SANE_DEBUG_DLL=255 SANE_DEBUG_<backend>=255 SANE_DEBUG_SANEI_<connection>=255 scanimage -L &> discovery_output

where <backend> is the name of backend which supports your device in capitals (f.e. PIXMA, AIRSCAN, GENESYS, HPAIO). You can find which backend supports your device here. If your device isn’t on the list and you were able to scan in the past or you know your device supports eSCL or WSD, use AIRSCAN. <connection> depends on how your device is connected — strings are TCP or USB.

Please attach the created discovery_output file as an attachment to the bugzilla ticket. If the file is too big (let’s say over 5MB), do follow the steps for dividing the logs.

Debugging scanning process

If the scanner is found, but an issue happens during scanning itself, we need to debug scanning process itself — which means debugging communication between backend and scanner when you start scanning a document.

The debugging scanning itself looks similar as discovery — setup the environment variables before running the command/scanning application and catch logs into a file. The command’s skeleton is (if you use xsane):

$ SANE_DEBUG_DLL=255 SANE_DEBUG_<backend>=255 SANE_DEBUG_SANEI_<connection>=255 xsane &> debug_log

or (once you find out device uri from scanimage -L — see the previous section):

$ SANE_DEBUG_DLL=255 SANE_DEBUG_<backend>=255 SANE_DEBUG_SANEI_<connection>=255 scanimage -d <device_uri> > out.pnm 2> debug_log

, where you substitute <device_uri> for the actual device uri, f.e. ‘hpaio:/net/laserjet_m1536dnf_mfp?ip=192.168.1.112’.

<backend> is the name of backend which supports your device in capitals (f.e. PIXMA, AIRSCAN, GENESYS, HPAIO). You can find which backend supports your device here. If your device isn’t on the list and you were able to scan in the past or you know your device supports eSCL or WSD, use AIRSCAN. <connection> depends on how your device is connected — strings are TCP or USB.

Please attach the created file — debug_log — as an attachment to the bugzilla ticket. If the file is too big (let’s say over 5MB), do follow the steps for dividing the logs.

Getting a scanner device uri

This point is basically a manual how to get a scanner uri for debugging scanning itself via scanimage. You don’t need to provide a scanner uri in GUI applications like xsane or simple-scan, because the application will do it for you or you can choose the scanner by a mouse click.

The scanimage -L command returns an output where device uri of the device is shown, f.e.:

$ scanimage -L
device `v4l:/dev/video0' is a Noname Integrated Camera: Integrated C virtual device
device `hpaio:/net/laserjet_m1536dnf_mfp?ip=192.168.1.112&queue=false' is a Hewlett-Packard laserjet_m1536dnf_mfp all-in-one

F.e.the string ‘hpaio:/net/laserjet_m1536dnf_mfp?ip=192.168.1.112&queue=false’ is a device uri for for Hewlett-Packard laserjet_m1536dnf_mfp all-in-one scanner.

Debugging HP scanner if it is supported by HPLIP

The hplip package doesn’t have unified logging, so some logs come out of HPAIO backend to standard output and HP internal utilities logs come to journal. So we need to capture both to get the understanding of situation.

It can be done this way:

• start capturing journal logs at background:

$ journalctl -f > journal_logs &

• trigger an action (discovery or scanning)

• kill the journalctl process, f.e. this way (if there is only one journactl process)

$ kill `pidof journalctl`

then attach the created file — journal_logs — as an attachment to the bugzilla ticket. Please do only one action per capture — that means if you are asked to attach log files for HP scanner discovery and scanning supported by hplip, you will attach as an attachment four files — discovery_output, journal_logs for discovery output, debug_logs and journal_logs for debug_logs.

Debugging sane-airscan

If your device supports eSCL or WSD (you can find it out from device specification — look for the mentioned protocols or AirScan), then its scanning functionality is supported by sane-airscan. Regarding debugging, on the top of usual logging sane-airscan gathers a communication dump and output image, which is helpful during investigation.

sane-airscan debugging can be enabled in /etc/sane.d/airscan.conf by setting:

[debug]
trace = /path/to/dir/where/debugfiles/will/be/saved
enable = true

Then do trigger your issue (discovery or scanning), go to the dir you defined in /etc/sane.d/airscan.conf, take all files from there and attach them to the bug ticket.

How to divide the logs

In case your debug log is too big for bugzilla to attach (because your issue doesn’t happen with the lowest settings or logs are big even with the lowest settings), do divide the logs to three files like this:

$ grep dll debug_log > debug_log_dll
$ grep <connection> debug_log > debug_log_connection
$ grep <backend> debug_log > debug_log_backend

<backend> is the name of backend which supports your scanner (pixma, genesys, plustek, hpaio, airscan etc.), <connection> is the type of connection you use for the device (tcp, usb).

The division makes the investigation more difficult (the person needs to have three opened files at the same time), so do divide the logs only if log file is too big.

Known issues

Here are several known issues, which arise with certain circumstances, and there isn’t general solution or upstream didn’t want to add the solution to its project:

cups-browsed

Cannot print due ‘No destination hostname provided by cups-browsed, is it running?’

cups-browsed sometimes loses connection to print server (usually with old ones, like cups-1.4.2) when laptop changes network connection (change of WiFi network or after hibernate/suspend). You can make printing working again with cancelling your jobs and restarting cups-browsed by

$ cancel -a
$ sudo systemctl restart cups-browsed

cups-browsed consumes large amount of CPU

Creating local printer queues takes long time for some printers with larger PPD file, so timeout of http connection will time out and it creates infinite loop of creating local printer queues. To solve this issue, please add

HttpLocalTimeout N
HttpRemoteTimeout N

into /etc/cups/cups-browsed.conf, where ‘N’ is number of seconds after which connection is timed out. Then restart cups-browsed service. This option is currently in Fedora 27 and above.

[SINCE FEDORA 27] cups-browsed creates different printer queue names than before

This issue is connected to remote cups queues, which are advertised by older CUPS version (usually below cups-1.5, e.g. RHEL 6). Cups-browsed creates local print queues named by printer’s DNS-SD ID by default and naming by remote cups queue is enabled again by adding:

LocalQueueNamingRemoteCUPS RemoteName

into /etc/cups/cups-browsed.conf and restart cups-browsed service.

Remote DNS-SD-advertised CUPS queue shredder on host barn.local is raw, ignored.

Server queues don’t appear in desktops.

jourcnalctl -u cups-browsed output shows:

Network interfaces: lo (127.0.0.1, localhost), eno1 (172.16.0.123, desk.example.com, 172
Avahi Resolver: Service 'HP LaserJet 4100 Series @ barn' of type '_ipps._tcp' in domain.....
Avahi-Resolver: Instance: HP LaserJet 4100 Series
Found CUPS queue/class: shredder on host barn.local.
Remote DNS-SD-advertised CUPS queue shredder on host barn.local is raw, ignored.
listening

# Set CreateRemoteRawPrinterQueues to "Yes" to let cups-browsed also
# create local queues pointing to remote raw CUPS queues. Normally,
# only queues pointing to remote queues with PPD/driver are created
# as we do not use drivers on the client side, but in some cases
# accessing a remote raw queue can make sense, for example if the
# queue forwards the jobs by a special backend like Tea4CUPS.

CreateRemoteRawPrinterQueues Yes

uncommenting / switching to Yes in /etc/cups/cups-brosed.conf solves the issue.

cups-filters

Printing takes a long time or doesn’t print at all

When your printer needs a lot of time to do printing (from your POV) or doesn’t print at all (some Xerox printers have such problems with gs renderer, so they are working again only with pdftops renderer), you can try to change the default postscript renderer. The default renderer in Fedora for most printers is gs filter from Ghostscript, but we have pdftops filter from Poppler for Brother, Minolta and Konica Minolta printers — this setup is called hybrid.

Other available renderer setups are gs (from Ghostscript), pdftops and pdftocairo (from Poppler), mupdf (from mupdf) and acroread (from adobe reader, not in Fedora official repositories), then you can set different default renderer for your print queue like this:

# lpadmin -p <printer-name> -o pdftops-renderer-default=gs/pdftops/pdftocairo/mudpf/acroread/hybrid

BEWARE: Most ‘slow’ printing issues are caused by PDF creating applications, which generates bad PDF file — and that bad generated PDF file is mostly the core of problem. To sum it up, slow printing issue can rise again with different PDF file, then it is on user’s decision: if he wants to print fast and probably sometimes change the default renderer, or slow printing is not such critical issue.

CUPS

[Fixed in F33 and later] Firefox, Evince (PDF viewer), GVim, Gedit, Gnome Control Center show a ‘dummy’/duplicate print queue, which doesn’t work

This bug is connected to every application which uses GTK print dialog. GTK dialog decided to take information about available from two sources — mDNS messages from Avahi and CUPS — this dummy/duplicate print queue is a print queue GTK created in its dialog based on Avahi messages, but it doesn’t exist in CUPS, because no one created it, and later GTK behaves like it exists in CUPS. So every time an user wants to print, GTK sends a request to CUPS for this queue, but it gets dropped by CUPS because the queue doesn’t exist.

The feature which GTK is trying to do here is called CUPS temporary queues — GTK developers is currently working on a immediate fix in this bugzilla. The future plan is to use cpdb-backend-cups backend in GTK, but right now we are focusing on the intermediate fix.

CUPS doesn’t take nicely some kinds of FQDN

CUPS sometimes has problems with some kinds of FQDN — that means when you use FQDN in ‘BrowsePoll’ directive in /etc/cups/cups-browsed.conf, CUPS doesn’t recognize it as valid hostname — it is solved by adding:

ServerAlias your.own.fully.qualified.hostname.com

into /etc/cups/client.conf and restarting cups service.

[F33+] Printing via IPPS doesn’t work

Fedora 33 came up with a raised bar regarding crypto-policies, so SSL and older TLS protocols are disabled on system level. The change breaks printing via IPPS to devices which don’t support newer protocols. You can set back legacy crypto support in crypto-policies via:

$ sudo update-crypto-policies --set DEFAULT:FEDORA32

The policy change transitionally has an impact on devices found by cups-browsed, because the daemon prefers IPPS uris if they are reported as available by printer/server.

HPLIP

First I would like to mention that we are not responsible for support HPLIP, which is downloaded and installed from HP website. Please install hplip rpms from official Fedora repositories at most cases.

Hp-plugin: file does not match its checksum. File may have been corrupted or altered

This common error is mostly caused by external causes (server outage, network outage), when wget tries to download plugin, but it returns only error message. It is connected with message:

Plugin download failed with error code = N

where N is return value of wget (man wget), which is used for downloading proprietary plugin. Solutions for this issue may vary — you can wait until servers go up again or try to install plugin, which you download manually from http://www.openprinting.org/download/printdriver/auxfiles/HP/plugins/ (select «Select and install an existing local copy of the plug-in file» during hp-setup or hp-plugin).

Unable to load cupsext

This error can occur when hplip is installed from HP website, or its dependencies are mixed python2 and python3 packages or installed by pip. This is solved by removing all hplip packages (hplip, hplip-gui, hplip-libs, hplip-common, libsane-hpiao) and installing them again all from repositories.

Missing hplip-gui

GUI tools and GUI parts of HP commands are moved to hplip-gui subpackage, because the main package can work without GUI, so the main package is smaller. The outcome of this decision is HP commands need to be run with ‘-i’ option for interactive mode, or hplip-gui subpackage needs to be installed.

Tools, which need to be run with ‘-i’ option for CLI or need to have hplip-gui installed for GUI:

hp-align
hp-clean
hp-colorcal
hp-diagnose_queues
hp-fab
hp-firmware
hp-info
hp-plugin
hp-sendfax
hp-setup
hp-testpage
hp-unload

Tools, which are in hplip-gui:

hp-check
hp-print
hp-systray
hp-toolbox
hp-devicesettings
hp-faxsetup
hp-linefeedcal
hp-makecopies
hp-printsettings
hp-wificonfig

HP printer isn’t discovered, doesn’t print or doesn’t print well

Some HP printers don’t work well with URIs provided by CUPS (dnssd, usb, ipp) or they need proprietary plugin from HP, which cannot be in Fedora because of licensing issues. For such printers please try to run:

hp-setup -i -g

for interactive mode, or:

hp-setup -g

for graphic mode. This command installs HP printers and HP scanners. If you have issue about HP printer/HP scanner, which isn’t discovered, doesn’t print or doesn’t print well, please try to install it by ‘hp-setup’, if it helps. If it doesn’t help, please file a bugzilla, attach output of hp-setup and mention that you tried ‘hp-setup’.

Device which needs plugin does not work after HPLIP update

Devices which need plugin can stop to work after update to newer HPLIP version — it is due the check for plugin version in the code. The check is necessary to prevent inconsitencies when new features in open sourced HPLIP need new proprietary libraries from plugin. To make your printer work again, just download and install plugin again with:

$ hp-plugin -i

Devices which require a binary plugin stopped to work on Fedora Silverblue/CoreOS

Devices which require a HP close source binary plugin need to have plugin installed every time you start/restart your PC by default. HP closed source script installs the plugins into a readonly directories, so the plugins are removed once you start/restart Fedora.
The workaround is to try if your device supports driverless printing and scanning, try hplip-plugin package from RPMFusion or keep installing the plugin everytime you want to print.

HP USB printer/scanner doesn’t work due a conflict on USB port

HPLIP proprietary binary plugins tends to conflict on the USB port where HP device is connected, if the HP device is capable of using IPP over USB and if ipp-usb package is installed. The solution is to remove hplip and have the device being maintained by ipp-usb and sane-airscan, because it provides newer open sourced protocols and you are not limited by problems caused by closed source plugins (needed to be reinstalled every time there is a new HPLIP version, they don’t work stable on Silverblue/CoreOS).

Terminology for printing and scanning

Printing

Print queue

Abstraction unit in CUPS for a printer — it has a device uri, which represents connection to the device, and can exist with classic driver (PPD file from different package) or without (driverless printing).
The entries you see in print dialogs and settings are those print queues. They can be permanent or temporary.

Permanent print queues

The queues with classic driver or driverless print queue which need to be shared further down the network.

Temporary print queues

The queue which don’t need to be installed at all — they show up during print dialog and they disappear once the printing is done successfully. They rely on driverless printing.

Remote CUPS queue

The queue on the different machine, where other cupsd process is running, than on the local machine. They are usually found in enterprise solutions, where printers aren’t in the same network as users or if admin wants a centralized monitoring above all printers.
In such solutions, users set up cups-browsed to install remote CUPS queue as local queues via BrowsePoll directive, or install a specific queue via GNOME. There can be a solution how to redirect mDNS messages which CUPS server advertises to the networks with users, but I haven’t been to setup this correctly yet.

Classic drivers

Those are the binaries and PPD files, which need to be installed for the device to work. This is older way of supporting devices, which will go away in the future.

Driverless printing (wireless/ethernet)

Most of modern devices (2010+) complies to AirPrint, Mopria or IPP Everywhere standard, which means they don’t need a classic driver for being able to print. Those devices have IPP (Internet Printing Protocol) 2.0+ implemented within, are capable to ‘advertise’ themselves via mDNS and they support document formats like PDF, PCLm, JPEG, Apple Raster or PWG Raster.

There are several prerequitises which need to fulfill in OS to have an access to the driverless feature:

• avahi-daemon must run
• there needs to be a ‘.local’ address resolver active — systemd-resolved or nss-mdns
• the device itself must have IPP port (631) and Bonjour/MDNS enabled
• IPP and MDNS need to be enabled in firewall

How does the driverless printing work under the roof (put it simply):

• CUPS sees the printer in mDNS messages via Avahi
• CUPS will find out the printer capabilities via IPP
• if there is a print job, CUPS will set up the filter chain to convert the incoming file into document format which printer understands (Apple Raster, PDF, PWG Raster, PCLm, JPEG)

In case it is needed, PPD file is generated by PPD generator in CUPS or by driverless binary.

One of the features which use driverless printing is CUPS temporary queues.

See manual how to check if your printer is capable of driverless printing.

Printing using a driver

This printing is similar to driverless printing in matter of setting up a filter chain, but:

• it can use limited mDNS and IPP functionality or it doesn’t use them at all
• all information about device capabilities is taken from PPD (Postscript Printer Description) file
• can use a specialized filters and specialized communication with the device (depends on driver)

The downsides of this approach is to rely on 3rd party drivers, you need to always install a permanent queue for it and it will go away in the future.

Printing raw data

No filters are started during this printing, the data are sent as they are to the target. This approach is usually used for printing to label printers, or, in the past, for printing to remote CUPS queue.
The same as classic drivers, this solution is deprecated and it will be removed in the future.

Printer applications

The binaries which provide support for older devices which aren’t capable of complying to driverless standards. The core idea is they will be capable of accepting the old driver and then advertise itself as a device capable of driverless printing. Then the new CUPS will be able to see them and user will be able to print via them as if they were temporary queues.
The currently available printer applications in Fedora are ippeveprinter (a part of CUPS — see cups-printerapp package) and lprint (provides support for devices which requires raw printing — mostly label printers). I’m planning to package PAPPL, the library for creating printer applications, and ps-printer-app, a printer application for printers which support Postscript.

Driverless printing (USB)

Driverless printing has its variant for devices which are connected via USB — it is covered by ‘IPP over USB’ standard. For make it work, you need ‘ipp-usb’ package, which will register the device with Avahi on localhost — then USB device will look as a wireless/ethernet device. The discovery/printing looks the same as with a wireless/ethernet device with driverless support.

See manual how to check for IPP-over-USB.

Scanning

Classic scanning (via hplip and sane-backends)

The classic scanning works via backends, which are binaries for communication with device. There are several backends, usually created by reverse engineering communication between scanner and MS Windows driver. None of classic backends implements a protocol, which is compatible with most devices available.

Driverless scanning

The driverless scanning uses sane-escl (not built in Fedora) and sane-airscan backends for communicating with newer devices. Those newer devices usually support eSCL (based on AirScan protocol by Apple) or WSD (Web Services for Devices by Microsoft), which sane-airscan is able to use.

Regarding USB scanning, it has the same requirement as printing. The device must support IPP over USB and ‘ipp-usb’ package must be installed to get driverless scanning via USB.

Useful tricks

How to find out whether my printer is capable of driverless printing?

• look for AirPrint among device specification
• Officially certified printers for IPP Everywhere
• check manual for enabling CUPS temporary queues — if your printer is seen in the end in CUPS commands that way, your printer is capable of driverless printing
• [USB devices only] check for IPP over USB (manual here).

How to find out my multifunction device or standalone scanner is capable of driverless scanning?

• check the device specification and look for eSCL/AirScan/WSD — if any of these are mentioned, the device is capable of driverless scanning
• most devices which advertise they can do AirPrint are capable of AirScan too
• [USB devices only] check for IPP over USB (manual here).

How to find out if my USB device supports IPP over USB

Check whether your USB device has a following text in lsusb -v output:

...
      bInterfaceClass         7 Printer
      bInterfaceSubClass      1 Printer
      bInterfaceProtocol      4 
      iInterface              0 
...

If the device has the bInterfaceClass 7, bInterfaceSubClass 1 and bInterfaceProtocol 4 in the sequence, it supports IPP over USB which is critical for USB device driverless printing and scanning.

How to install a print queue

The answer is you don’t have to install at all  if your device is new enough, is in your local network or is an USB device, has IPP/AirPrint/mDNS enabled and your avahi-daemon is running, CUPS is able to create a temporary queue for you right away in the print dialog, print via it and remove it after successful printing. But there are still use cases when permanent installation is needed like sharing a print queue, different print queue defaults or printer being in different subnet, so I will cover a permanent instalation too.

How to setup CUPS temporary queues with network printer

If your printer is capable of AirPrint, IPP and MDNS is enabled in your printer and printer , then to get CUPS temporary queues working you need:

• have avahi-daemon running:

$ sudo systemctl start avahi-daemon

• have cups.socket enabled and running running:

$ sudo systemctl enable cups.socket
$ sudo systemctl start cups.socket

• enable IPP and MDNS in your firewall settings

After this the temporary queue will appear in the print dialog and you don’t need to install a specific print queue unless you have a reason for it.

You can check if your printer is seen in mDNS messages by (avahi-tools must be installed):

$ avahi-browse -avrt
...
= enp0s25 IPv4 HP LaserJet M1536dnf MFP (42307C)             _ipp._tcp            local
   hostname = [NPI42307C.local]
   address = [192.168.1.10]
   port = [631]
   txt = ["UUID=434e4239-4243-4a42-5859-3c4a9242307c" "Scan=T" "Duplex=T" "Color=F" "note=" "adminurl=http://NPI42307C.local." "priority=10" "product=(HP LaserJet M1536dnf MFP)" "ty=HP LaserJet M1536dnf MFP" "URF=CP99,W8,OB10,PQ3-4-5,DM1,IS1-4,MT1-2-3-5,MT1-2-3-5,RS600" "rp=ipp/printer" "pdl=application/postscript,application/vnd.hp-PCL,application/vnd.hp-PCLXL,application/pdf,image/urf" "qtotal=1" "txtvers=1"]
...

and if CUPS or its backends see the printer by commands:

(lists all existing print queues — permanent or temporary)

$ lpstat -e
HP_LaserJet_M1536dnf_MFP_42307C_

or

(lists all devices, which CUPS sees in the local network or USB)

$ lpinfo -l -v
...
Device: uri = ipp://HP%20LaserJet%20M1536dnf%20MFP%20(42307C)._ipp._tcp.local/
        class = network
        info = HP LaserJet M1536dnf MFP (driverless)
        make-and-model = HP LaserJet M1536dnf MFP
        device-id = MFG:HP;MDL:LaserJet M1536dnf MFP;CMD:PDF,PS,PCL,AppleRaster,URF;
        location = 
...

How to setup CUPS temporary queues with USB printer

USB printers have only one additional prerequisite, installing ipp-usb, which will transform IPP over USB devices to network printer on localhost:

$ sudo dnf -y install ipp-usb

Then you can follow the steps in manual for network printers.

How to install a permanent print queue

1) via CUPS web UI

• start cups.service

$ sudo systemctl start cups

• go to localhost:631 in your browser, and select ‘Administration’ tab
• click on ‘Add printer’ and follow the dialogs

2) via CLI commands

• you will need a device uri — <device_uri>, f.e.:

$ lpinfo -l -v
...
Device: uri = ipp://HP%20LaserJet%20M1536dnf%20MFP%20(42307C)._ipp._tcp.local/
              ================================================================

and a driver name — <driver>, f.e.:

$ lpinfo -m
....
everywhere IPP Everywhere
==========
...

$ lpadmin -p <name> -v <device_uri> -m <driver> -E

where <device_uri> and <driver> are underscored strings from previous commands and <name> is a print queue name, which is chosen by you.

How to install a scanner

Scanners in Linux don’t have to be installed the same way as printers are if they are in the same network or connected via USB — you just need sane-backends to be installed and any scanning application will communicate with scanner/multifunction device via the backend which supports the scanner.

However, the older HP scanners and multifunction devices require an additional package — hplip — and its binary plugins downloaded via hp-plugin -i if they aren’t supported by sane-backends already.

How to make driverless scanning to work

For LAN located and USB devices:

• have avahi-daemon enabled and running

$ sudo systemctl enable avahi-daemon
$ sudo systemctl start avahi-daemon

• enable MDNS in firewall
• [USB devices only] install ipp-usb

For network scanners in a different network:

• set the scanner device uri in /etc/sane.d/airscan.conf — see:

man sane-airscan

How to setup mDNS with systemd-resolved

systemd-resolved is enabled and running by default since F33 and can be setup to work with Avahi on mDNS support which CUPS needs — Avahi does the advertising, registering and sharing devices, and resolved will handle ‘.local’ address resolution. It will work with following steps:

• put ‘MulticastDNS=resolve’ into /etc/systemd/resolved.conf

$ sudo systemctl restart systemd-resolved
$ sudo nmcli connection modify <connection_name> connection.mdns yes connection.llmnr yes
$ sudo systemctl restart NetworkManager

How to compress files

Example:

$ tar -czvf cups-information.tar.gz /etc/cups cups.logs troubleshoot.txt lpinfo.log

Restarting cups service

You restart cups service with:

sudo systemctl restart cups.service

cupsd-logs(5)

Description

Access Log File Format

The group field always contains «-«.

The user field is the authenticated username of the requesting user. If no username and password is supplied for the request then this field contains «-«.

The date-time field is the date and time of the request in local time and is in the format «[DD/MON/YYYY:HH:MM:SS +ZZZZ]».

The method field is the HTTP method used: «GET», «HEAD», «OPTIONS», «POST», or «PUT». «GET» requests are used to get files from the server, both for the web interface and to get configuration and log files. «HEAD» requests are used to get information about a resource prior to a «GET». «OPTIONS» requests are used to upgrade connections to TLS encryption. «POST» requests are used for web interface forms and IPP requests. «PUT» requests are used to upload configuration files.

The resource field is the filename of the requested resource.

The version field is the HTTP specification version used by the client. For CUPS clients this will always be «HTTP/1.1».

The status field contains the HTTP result status of the request, as follows:

The bytes field contains the number of bytes in the request. For POST requests the bytes field contains the number of bytes of non-IPP data that is received from the client.

The ipp-operation field contains either «-» for non-IPP requests or the IPP operation name for POST requests containing an IPP request.

The ipp-status field contains either «-» for non-IPP requests or the IPP status code name for POST requests containing an IPP response.

Error Log File Format

The date-time field contains the date and time of when the page started printing. The format of this field is identical to the data-time field in the access_log file.

The message field contains a free-form textual message. Messages from job filters are prefixed with «[Job NNN]» where «NNN» is the job ID.

Page Log File Format

The printer field contains the name of the printer that printed the page. If you send a job to a printer class, this field will contain the name of the printer that was assigned the job.

The user field contains the name of the user (the IPP requesting-user-name attribute) that submitted this file for printing.

The job-id field contains the job number of the page being printed.

The date-time field contains the date and time of when the page started printing. The format of this field is identical to the data-time field in the access_log file.

The num-sheets field provides the total number of pages (sheets) that have been printed on for the job.

The job-billing field contains a copy of the job-billing or job-account-id attributes provided with the IPP Create-Job or Print-Job requests or «-» if neither was provided.

The job-originating-host-name field contains the hostname or IP address of the client that printed the job.

The job-name field contains a copy of the job-name attribute provided with the IPP Create-Job or Print-Job requests or «-» if none was provided.

The media field contains a copy of the media or media-col/media-size attribute provided with the IPP Create-Job or Print-Job requests or «-» if none was provided.

The sides field contains a copy of the sides attribute provided with the IPP Create-Job or Print-Job requests or «-» if none was provided.

Источник

CUPS (Русский)/Troubleshooting (Русский)

В этой статье рассматриваются все неспецифические (то есть не связанные с каким-либо одним принтером) проблемы CUPS и драйверов принтеров (но не проблемы, связанные с совместным использованием принтеров), включая методы определения точной природы проблемы и решения выявленной проблемы.

Введение

Наилучший способ борьбы с неисправностями — это выставить ‘LogLevel’ в файле /etc/cups/cupsd.conf на:

А потом посмотреть вывод из файла /var/log/cups/error_log например так:

Символы слева от вывода означают следующее:

• D=Debug(отладка)
• E=Error(ошибка)
• I=Information(информация)
• И так далее

Следующие файлы также могут быть полезны:

• /var/log/cups/page_log — каждый раз при успешной печати, пишет новую запись
• /var/log/cups/access_log — записывает всю активность на cupsd http1.1 сервере

Также, если вы хотите решить свои проблемы, важно понимать, как вообще работает CUPS. Вот краткая информация об этом:

1. Когда вы жмёте ‘печать’ приложение отправляет .ps-файл (PostScript, язык-скрипт, который описывает, как выглядит страница) в систему CUPS (так происходит в большинстве программ).
2. CUPS смотрит на PPD-файл (файл описания принтера) и находит, фильтры которые ему нужно использовать для преобразования .ps-файла в файл, который понимает ваш принтер (например, PJL,PCL). Обычно для этого ему требуется ghostscript.
3. GhostScript принимает ввод и решает, какие фильтры ему использовать, потом применяет их и преобразовывает .ps-файл в формат, который понимает принтер.
4. Затем файл передается бэкенду. Например, если у вас принтер подключен к usb порту, то используется usb бэкенд

Распечатайте документ и посмотрите error_log , чтобы получить более подробное и правильное представление об процессе печати.

Проблемы, возникающие в результате обновлений

Проблемы возникшие после обновления CUPS и сопутствующего ему набора программ

CUPS останавливается

Существует вероятность, что для правильной работы в обновленной версии понадобится новый файл конфигурации. Например, получение сообщения «404 — page not found» при попытке входа в панель управления CUPS через localhost:631.

Для того, чтобы воспользоваться новым конфигом, скопируйте /etc/cups/cupsd.conf.default в /etc/cups/cupsd.conf (при необходимости сделайте резервную копию старого конфига) и, чтобы новые настройки вступили в силу, перезапустите CUPS.

Для всех заданий — «остановлено»

The factual accuracy of this article or section is disputed.

Если для всех отправленных на печать заданий установился статус «остановлено» («stopped»), — удалите принтер и установите его заново. Для этого войдите в веб-интерфейс CUPS, перейдите Принтеры > Удалить Принтер.

Для проверки настроек принтера перейдите во вкладку Принтеры, затем скопируйте отображаемую информацию. Далее нажмите на Администрирование. В выпадающем списке кликните Изменить принтер, перейдите к следующей странице(ам), и так далее.

Для всех заданий — «Принтер не отвечает»

Для сетевых принтеров, поскольку CUPS подключается через URI, необходимо убедиться, что в DNS настроен доступ к принтерам по IP. Например, если принтер подключен следующим образом:

то имя хоста ‘BRN_020554’ должно соответствовать IP принтера, управляемого сервером CUPS. Если используется Avahi, убедитесь, что разрешение имени хоста Avahi работает.

Альтернативно, замените имя хоста, используемое в URI, IP-адресом принтера.

Версия PPD не совместима с gutenprint

И перезагрузите CUPS (будет выведено соответствующее сообщение после установки gutenprint).

Проблемы с сетью

Не удается найти принтер

Даже если CUPS обнаруживает сетевые принтеры, вы все равно можете получить ошибку «Не удается найти принтер» («Unable to locate printer») при попытке распечатать что-либо. Чтобы решить эту проблему, включите .разрешение локального имени хоста Avahi. Для получения дополнительной информации смотрите CUPS (Русский)#Сеть.

Эта проблема может возникать и при использовании файрвола (межсетевой экран, брандмауэр). Возможно, вам придется отключить его или установить корректные правила. Если вы используете system-config-printer для обнаружения сетевых принтеров, тогда он сделает все это автоматически.

Старый сервер CUPS

Начиная с версии CUPS 1.6, клиент по умолчанию использует IPP 2.0. Если сервер использует CUPS version=1.1 , описанной в Таблице 2. Опции URI IPP.

Общий принтер работает локально, но удаленный компьютер не печатает

Это вызвано тем, что задание на печать отправляется через фильтр дважды, один раз на локальном компьютере и один раз на удаленном. Смотрите также предупреждение на главной странице CUPS.

Не удается найти файл PPD

Убедитесь, что Avahi настроен правильно. В частности, проверьте, что nss-mdns установлен и настроен в /etc/nsswitch.conf .

USB-принтеры

Конфликт с SANE

Если у вас также запущен SANE, возможно, что он конфликтует с CUPS. Чтобы исправить это, создайте правило Udev, обозначающее устройство как совпадающее с libsane:

Конфликт с usblp

Доступ к USB-принтерам можно получить двумя способами: модулем ядра usblp и libusb. Первый — это классический способ. Это просто: данные отправляются на принтер, записывая их в файл устройства в виде простого последовательного потока данных. Чтение одного и того же файла устройства позволяет использовать двунаправленный доступ, по крайней мере, для таких вещей, как считывание уровней чернил, статуса или информации о возможностях принтера (PJL). Он работает очень хорошо для простых принтеров, но для многофункциональных устройств (принтер/сканер) он не подходит, и производители, такие как HP, поставляют свои собственные бэкенды. Источник: здесь.

Если у вас возникли проблемы с работой USB-принтера, вы можете попробовать запрет загрузки для модуля ядра usblp :

Пользователям кастомного ядра может потребоваться вручную загрузить модуль ядра usbcore , прежде чем продолжить.

После установки модулей подключите принтер и проверьте, обнаружило ли его ядро, выполнив следующие действия:

Если вы используете usblp , вывод должен указывать на то, что принтер был обнаружен следующим образом:

Если вы запретили загрузку usblp , вы увидите что-то вроде:

USB autosuspend

Ядро Linux автоматически приостанавливает USB-устройства, когда есть поддержка драйверов и устройства не используются. Это может сэкономить электроэнергию, но некоторые USB-принтеры считают, что они не подключены, когда ядро приостанавливает USB-порт, предотвращая печать. Это можно устранить, отключив autosuspend для конкретного устройства, для получения дополнительной информации смотрите Power management#USB autosuspend.

Плохие разрешения

Проверьте разрешения USB-порта принтера. Получите номер шины (BUSID) и устройства (DEVID) от lsusb :

Проверьте владельца, просмотрев devfs:

Демон cups запускается от пользователя «cups» и относится к группе «lp», поэтому либо этому пользователю, либо группе требуется доступ на чтение и запись в USB-устройство. Если вы считаете, что разрешения выглядят неправильно, вы можете временно изменить группу и разрешение:

Затем проверьте, может ли cups теперь видеть устройство USB правильно.

Чтобы сделать постоянное изменение разрешения, которое будет запускаться автоматически при каждом запуске компьютера, добавьте следующую строку.

После редактирования перезагрузите правила udev этой командой:

Каждая система может отличаться, поэтому обратитесь к вики-странице udev (Русский)#Список атрибутов устройства.

Проблемы с HP

CUPS: «/usr/lib/cups/backend/hp failed»

The factual accuracy of this article or section is disputed.

Убедитесь, что dbus установлен и запущен. Если ошибка повторяется, попробуйте запустить avahi-daemon.

Попробуйте добавить принтер в качестве сетевого принтера, используя протокол http:// .

CUPS: «Печать завершена», но принтер не печатает.

Это происходит на принтерах HP, когда вы выбираете (старый) драйвер hpijs (например, для Deskjet D1600 series). Вместо этого используйте драйвер hpcups.

Некоторые принтеры HP требуют, чтобы их прошивка загружалась с компьютера при каждом включении принтера. Вы можете столкнуться с этой проблемой, если есть проблема с udev (или аналогом), и правило загрузки прошивки никогда не запускается. В качестве обходного пути вы можете вручную загрузить прошивку на принтер. Убедитесь, что принтер подключен и включен, затем выполните

CUPS: ‘»foomatic-rip» not available/stopped with status 3’

Если, во время использования принтера HP, задания появляются в очереди, но все завершаются со статусом ‘остановлен’ (‘stopped’), а в /var/log/cups/error_log возникает одно из следующих сообщений об ошибках:

CUPS: «Filter failed»

Ошибка «filter failed» может быть вызвана некоторым количеством причин. Журнал ошибок CUPS (по умолчанию /var/log/cups/error_log ) должен записывать, какой фильтр не удалось загрузить и почему.

Отсутствует ghostscript

Установите ghostscript ( /usr/lib/cups/filter/gstoraster нуждается в его запуске).

Отсутствует foomatic-db

Установите foomatic-db и foomatic-db-ppds . Это помогает в некоторых случаях.

Avahi не включен

Устаревший плагин

Эта ошибка может указывать на то, что плагин устарел (версия несовместима) и может произойти после обновления системы, возможно, появится сообщение Plugin error в журнале (логе). Если вы установили hplip-plugin AUR , вам нужно обновить пакет, иначе перезапустите hp-setup -i , чтобы установить последнюю версию плагина.

Устаревшая конфигурация принтера

Начиная с hplip-plugin AUR версии 3.17.11 hpijs больше не доступен. Если у вас есть принтеры, использующие hpijs, они не будут печатать. Необходимо перенастроить их и выбрать вместо этого новый драйвер hpcups.

Вы можете проверить, если это ваш случай, посмотрев в error_log cups`а:

CUPS: печатает только пустую страницу и страницу с сообщением об ошибке на HP LaserJet

This article or section is out of date.

Существует ошибка, которая приводит к сбою CUPS при печати изображений на HP LaserJet (в моем случае 3380). Ошибки были зафиксированы и исправлены в Ubuntu. Первая страница пуста, вторая страница содержит следующее сообщение об ошибке:

Чтобы устранить проблему, выполните следующую команду как суперпользователь (root):

HPLIP 3.13: Плагин установлен, но HP Device Manager жалуется на его отсутствие

Возможно, проблема связана с изменением прав доступа файла, которое было внесено в /var/lib/hp/hplip.state . Чтобы исправить проблему, достаточно простых команд chmod 644 /var/lib/hp/hplip.state и chmod 755 /var/lib/hp . Для получения дополнительной информации, пожалуйста, прочитайте эту ссылку.

hp-toolbox: «Unable to communicate with device»

Разрешение проблемы

The factual accuracy of this article or section is disputed.

Может потребоваться добавить пользователя в группы lp и sys .

Виртуальный CDROM у принтеров

Это также может быть вызвано принтерами, такими как P1102, которые предоставляют виртуальный привод CD-ROM для драйверов MS Windows. Появляется lp dev, а затем исчезает. В этом случае попробуйте пакеты usb-modeswitch и usb-modeswitch-data, что позволяет отключить «Smart Drive» (правила udev, включенные в указанные пакеты).

Сетевые принтеры

Это также может происходить с сетевыми принтерами, использующими динамические имена хостов, если avahi-daemon не запущен. Другая причина заключается в том, что hp-setup не удалось найти принтер, потому что IP-адрес принтера изменился из-за DHCP. Если это так, подумайте о добавлении резервирования DHCP для принтера в конфигурации сервера DHCP.

hp-setup просит указать PPD-файл для обнаруженного принтера

Кроме того, при выборе файла PPD в графическом режиме hp-setup поле не обновляется и сообщение об ошибке не отображается.

Или, если вы используете интерактивный (консольный) режим, можно столкнуться с чем-то похожим на это даже при введении правильного пути к файлу ppd:

Решение заключается в установке и запуске cups перед запуском hp-setup .

hp-setup: «Qt/PyQt 4 initialization failed»

Установите пакет python-pyqt4 AUR , который дополнительно требуется (optdepend) для hplip . Альтернативно вы можете запустить hp-setup с интерфейсом командной строки с помощью флага -i .

hp-setup: находит принтер автоматически, но сразу после этого сообщает «Unable to communicate with device» при печати тестовой страницы

Это, по крайней мере, происходит с hplip 3.13.5-2 у принтера HP Officejet 6500A через локальное сетевое соединение. Чтобы решить проблему, укажите IP-адрес принтера HP для hp-setup, чтобы обнаружить принтер.

hp-setup: «KeyError: ‘family-class’»

Если при добавлении принтера в пользовательском интерфейсе он не работает, или вы получили KeyError: ‘family-class’ от hp-setup , возможно потребуется обновить вручную /usr/share/hplip/data/models/models.dat .

Проверьте определен ли раздел family-class=Undefined для вашего принтера. Если нет, добавьте это:

Другие

Принтер «приостановлен — «Paused»» или «Остановлен» cо статусом «Рендеринг завершен»

Низкий уровень чернил

При низком уровне чернил некоторые принтеры зависают со статусом «Рендеринг завершен» («Rendering completed»), и, если это сетевой принтер, принтер может даже стать недоступным для CUPS, несмотря на то, что он правильно подключен к сети. Замена картриджа (картриджей) с низким уровнем чернил в этом случае вернет принтер в статус «Готов» («Ready») и, если он — сетевой принтер, то он станет снова доступным для CUPS.

Завершение печати из-за ошибок авторизации

Если удаленный принтер запрашивает аутентификацию, CUPS автоматически добавит директиву AuthInfoRequired для принтера в /etc/cups/printers.conf . Однако некоторые графические приложения (например, некоторые версии LibreOffice [1]) не имеют возможности запрашивать учетные данные, поэтому печать завершилась с ошибкой. Чтобы исправить это, укажите требуемое имя пользователя и пароль в URI. Для получения дополнительной информации смотрите [2], [3].

Unknown supported format: application/postscript

(Не найдена поддержка формата: application/postscript)

в /etc/cups/mime.convs и:

Ошибка задания для печати (Print-Job) client-error-document-format-not-supported

Попробуйте установить пакет foomatic и используйте драйвер foomatic.

Не удается получить список драйверов принтера

(Также применимо к ошибке «-1 не поддерживается!»)

Попробуйте удалить драйверы Foomatic или обратитесь к CUPS/Принтероспецифичные проблемы#HPLIP для обходного пути.

lp: Error — Scheduler Not Responding

Если вы получите эту ошибку, убедитесь, что CUPS запущен, переменная окружения CUPS_SERVER не установлена и /etc/cups/client.conf корректный.

Сообщение об ошибке: «Using invalid Host»

Попробуйте добавить ServerAlias * в /etc/cups/cupsd.conf .

Не удается отправить на печать из LibreOffice

Если вы можете распечатать тестовую страницу с веб-интерфейса CUPS, но не из LibreOffice, попробуйте установить пакет a2ps .

Вывод принтера сдвинут

По-видимому, это связано с неправильным размером страницы, установленным в CUPS.

Принтер не работает (приостановлен — «Paused») после ошибки

Когда во время печати возникает ошибка, принтер в CUPS может перестать отвечать на запросы. lpq сообщает, что принтер is not ready (не готов), его можно активировать с помощью cupsenable . В веб-интерфейсе CUPS принтер отображается как приостановлен — «Paused», его можно возобновить с помощью Восстановить печать.

Чтобы CUPS автоматически активировал принтер, измените политику ошибок с стандартной настройки Останавливать принтер (stop-printer) на Повторить задание (retry-this-job).

Samsung: URF ERROR — Incomplete Session by time out

Эта ошибка обычно возникает при печати файлов по сети через IPP на принтерах Samsung и решается с помощью пакета samsung-unified-driver AUR .

Brother: Принтер печатает несколько копий

Иногда принтер печатает несколько копий документа (например, MFC-9330CDW напечатал 10 копий). Решение заключается в обновлении прошивки принтера.

Обычный пользователь не может изменять настройки принтера или удалять определенные задания

Если обычный пользователь должен иметь возможность изменять настройки принтеров или управлять очередью принтера, пользователь может быть добавлен в группу sys .

Источник

CUPS’ error_log FAQ

General Questions

What is the error log?

What is the name of the CUPS error log?

error_log

Where is the error_log?

It is usually located in /var/log/cups/

Enabling Logging

How come the **»error_log»** doesn’t show much information?

In the default configuration, there is not enough logging information
to deal with printing failures. Change the LogLevel
to debug.

How do I change the logging level?

After enabling Logging, why are no more error reported to the error_log file?

CUPS Log Errors

Why are there no references to ghostscript in the log?

[06/Feb/2003:18:46:20 -0500] [Job 44] foomatic-gswrapper: 
gs '-dBATCH' '-dPARANOIDSAFER' '-dQUIET' '-dNOPAUSE' '-sDEVICE=ijs' 
'-sIjsServer=hpijs' '-sDeviceManufacturer=HEWLETT-PACKARD' 
'-sDeviceModel=DESKJET 540' '-dDEVICEWIDTHPOINTS=612' 
'-dDEVICEHEIGHTPOINTS=792' '-r300' 
'-sIjsParams=Quality:Quality=0,Quality:ColorMode=2,Quality:MediaType=0,Quality:PenSet=1' 
'-dIjsUseOutputFD' '-sOutputFile=| cat >&3' '/dev/fd/0' 3>&1 1>&2

**»cupsd: Child exited with status 1!»**

Try running cupsd as root.

**»unable to evaluate datablob»**

Check permissions on the spool directory.

**»cupsdoprint: relocation error: cupsdoprint: undefined symbol: strlcpy»**

Upgrading to KDE3.1 (the ASPlinux packages).

**»Warning — hp_psc_950: Bad printcap entry — missing ‘sd’ or ‘client»’**

If this error is from trying to print with lpr, you have probably installed
CUPS on top of another spooler (lpd,lpq, or lprng) and the lpr command is not
the CUPS version.

**»/usr/local/sbin/lpdomatic: unable to evaluate datablob»**

**»media tray empty»**

**»[Job 28] /usr/lib/cups/filter/foomatic-rip: No such file or directory»**

Looks like you need to install the filter at /usr/lib/cups/filter/foomatic-rip
Read the appropriate instructions onCUPSDocumentation

**»»/usr/local/var/spool/cups/d00032-001″ — Permission denied»**

**»Denying user «» access to printer?»**

lpadmin -p printername -u allow:root,username1,username2,...

**»/usr/bin/foo2zjs-wrapper: line 141: gs: command not found»**?

Your ghostscript be found. Please install ghostscript.

**»Unable to convert file 0 to printable format for job 4!»**

**»Couldn’t exec foomatic-gswrapper -q»**?

Make sure /usr/local/bin/foomatic-gswrapper has execution
permissions. If necessary, chmos a+rx /usr/local/bin/foomatic-gswrapper.

Error: /invalidfont in findfont?

Install GhostScript fonts.

YOU DO NOT HAVE YOUR FONTS INSTALLED!!?

Install GhostScript fonts.

**»server-error-service-unavailable»**?

This may be a permissions problem in the spool directory.

**»sh: line 1: hpijs: command not found»**

Your hpijs program cannot be found. Make sure hpijs exists,
and is executable.

**»Can’t find initialization file gs_init.ps»**?

**»Unknown device: ijs»**?

Your version of GhostScript does not have the “ijs” driver
compiled in. This driver is necessary for HPIJS to work.

**»cat: write error: Broken pipe»**?

It looks like the pnm2ppa is not
installed. See the “^^^^^” above) What does “which pnm2ppa” say?