CUPS – Druckprobleme beheben

Brandon Nielsen, Zdenek Dohnal Version F35 onwards Last review: 2022-02-10

Sollten Sie Probleme beim Drucken haben, lesen Sie bitte die Seite common bugs, bevor Sie einen Fehlerbericht einreichen. Falls Ihr Problem dort nicht aufgeführt ist oder keine der vorgeschlagenen Lösungen funktioniert, können Sie einen Fehlerbericht einreichen, damit wir Fedora auf Ihrer Hardware optimieren können.

Identifizieren Ihres Problemgebiets

Druckprobleme können recht komplex sein und erfordern aktive Zusammenarbeit oder die Anforderung vieler Daten vom Melder durch den Betreuer, um diesem zumindest das Verständnis und (falls es sich nicht um ein hardwarespezifisches Problem handelt) das Reproduzieren des Problems zu ermöglichen. Daher bitten wir Sie um Geduld und darum, das Problem für die Betreuer so weit wie möglich einzugrenzen.

Diese können sein:

Probleme beim Erkennen oder Verbinden mit dem Drucker (es können Probleme mit dem CUPS-Backend, Avahi, libusb oder cups-browsed vorliegen)
Zugriffsprobleme (korrekte/falsche Konfiguration in cupsd.conf oder deren fehlerhafte Interpretation durch den cupsd-Daemon, schlechte Zusammenarbeit mit NIS, SSSD…),
Drucken mit Hilfe von Samba (Probleme mit dem SMB-Backend, das Teil von Samba ist) oder mit Samba, das über Kerberos authentifiziert ist (samba_krb5_printing),
Probleme mit Filtern, die beim Filtern des Dokuments in ein vom Drucker unterstütztes Dokumentformat verwendet werden und Einfluss darauf haben, wie oder ob das Dokument überhaupt gedruckt wird (Probleme mit Filtern - pdftops, pdftopdf, pstops, bannertopdf usw. - oder Probleme mit Binärdateien oder Bibliotheken, die von den Filtern verwendet werden - libgs, qpdf, popppler…),
Probleme mit PostScript-Druckerbeschreibungsdateien, die eine veraltete Methode zur Definition von Druckerfunktionen wie unterstützten Seitengrößen, Rändern usw. darstellen…

Ohne mögliche Einschränkungen oder Probleme in der Firmware oder Hardware des Druckers selbst zu erwähnen – es sind alle Informationen oder Hinweise zur Eingrenzung des Problems willkommen.

Am besten beginnen Sie damit, Dateien mit den weiter unten beschriebenen Protokollen anzuhängen.

CUPS-Protokollierung

Seit Fedora 28 werden alle CUPS-Protokolle standardmäßig in ein Journal umgeleitet (vor Fedora 28 wurde error_log standardmäßig in ein Journal umgeleitet).

Wir müssen zwei verschiedene Methoden zur Erfassung der gesamten CUPS-Protokolle im Zusammenhang mit Vorfällen definieren: eine für den Fall, dass die fehlerhafte Druckwarteschlange nicht von HPLIP bereitgestellt wird, und eine für den Fall, dass sie es wird. Sie unterscheiden sich in der Filteroption von journald. Wenn Sie eine Nicht-HPLIP-Warteschlange zum Debuggen verwenden, können Sie die Protokolle der CUPS-Systemd-Unit (mit '-u cups') erfassen, da alle Fehlermeldungen korrekt an die Protokollierung der CUPS-Systemd-Unit weitergeleitet werden und nach der Filterung in der Ausgabe verfügbar sind. Die HPLIP-Bibliotheken sind nicht entsprechend implementiert (das Upstream-Projekt reagiert nicht auf mögliche Korrekturen, und das Problem ist nicht kritisch genug, um einen Downstream-Patch unnötig zu verzögern), daher werden deren Meldungen nicht für die CUPS-Systemd-Unit markiert und nach dem Aufruf von journald mit '-u cups' herausgefiltert. Für solche Warteschlangen ist ein ungefiltertes journald-Protokoll erforderlich.

Das ungefilterte, an einen Vorfall gebundene journald-Protokoll ist nur für HPLIP-Druckwarteschlangen (deren Geräte-URI mit hp:// beginnt) erforderlich und für andere Warteschlangen unerwünscht, da es bei größeren Fällen schwer lesbar sein kann. Bitte fügen Sie das an einen Vorfall gebundene journald-Protokoll nur dann bei, wenn es unbedingt notwendig ist.

Ort der CUPS-Protokolle

Die CUPS-Protokollierung erfolgt standardmäßig im Systemjournal. Die Protokollierung in eine Datei kann jedoch in der Datei /etc/cups/cups-files.conf mit der Direktive ErrorLog konfiguriert werden. Wenn Sie die Standardeinstellungen ändern möchten, ist der Name der Protokolldatei irrelevant. Es wird jedoch empfohlen, die Datei im Pfad /var/log/cups abzulegen, da SELinux sonst den Zugriff von cupsd blockiert.

Die Protokollierung in eine Datei hat folgende Nachteile (ohne weitere Maßnahmen):

Es ist nicht möglich, nur die mit einem Auftrag verbundenen Protokolle abzurufen, ohne weitere Befehle zu verketten
Es können keine Protokolle für den angegebenen Zeitraum abgerufen werden, ohne weitere Befehle zu verketten

Zum Erfassen von ereignisbezogenen Protokollen kann beispielsweise tail -f verwendet werden:

tail -f /var/log/cups/error_log

CUPS-Debug-Protokollierung aktivieren

Aktivieren Sie die vollständigen Debugging-Informationen mit:

$ cupsctl LogLevel=debug2

CUPS-Auftragsprotokoll

Tritt das Problem beim Senden eines Dokuments zum Drucken auf oder während des Druckvorgangs, erfassen Sie bitte die Protokolle für diesen Druckauftrag. Falls ein Auftragsprotokoll verfügbar ist, muss dieses UNBEDINGT ANGEHÄNGT WERDEN.

CUPS für die Auftragsprotokollierung vorbereiten

Um das spezifische Auftragsprotokoll einsehen zu können, aktivieren Sie bitte Folgendes:

PreserveJobFiles Yes

in Ihre Datei /etc/cups/cupsd.conf ein und starten Sie den CUPS-Dienst neu. Vergessen Sie nicht, die Zeile nach Abschluss der Fehlersuche wieder zu entfernen. Der Befehl lpstat -W all liefert nach der Ausgabe keine Werte, wenn Sie die entsprechende Direktive nicht aktivieren.

Auftragsprotokoll für eine bestimmte Auftrags-ID abrufen

Um ein Auftragsprotokoll zu erfassen, benötigen Sie die Auftrags-ID (JID) des Auftrags – das ist die Zahl nach dem Bindestrich in der Anforderungs-ID:

Die Anforderungs-ID sieht wie folgt aus:

<Druckerwarteschlangenname>-<JID>

und kann im Terminal angezeigt werden, wenn Sie ein Dokument mit dem Befehl lp zum Drucken senden:

$ lp -d <Warteschlangenname> <Datei1> ... <DateiN>
request id is <Warteschlangenname>-<JID> (N Datei(en))

Oder wenn Sie die Aufträge auflisten (siehe man lpstat) – der neueste Auftrag steht am Ende:

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

Sie können die neuesten Auftragsprotokolle automatisch abrufen (wenn Sie awk installiert haben und lpstat -W alle Aufträge zurückgibt), indem Sie:

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

Oder manuell, falls Sie die JID selbst gefunden haben:

journalctl -u cups JID=<JID> > cups_job_log

Ereignisbezogenes cupsd-Protokoll (defekte Druckerwarteschlange wird von HPLIP nicht unterstützt)

Manchmal lässt sich der Fehler nicht einem bestimmten Druckauftrag zuordnen, daher ist das Auftragsprotokoll nutzlos. Ein ereignisbezogenes cupsd-Protokoll ist erforderlich.

Wie man mit der Erfassung von ereignisbezogenen CUPSD-Protokollen beginnt

Bitte geben Sie im neuen Terminal/Terminal-Reiter Folgendes ein:

journalctl -f -u cups > cups_whole_log

Wie man ereignisbezogene CUPSD-Protokollierung erhält

Nachdem Sie die Fehlerbedingung ausgelöst haben, die Sie zu diagnostizieren versuchen, z. B. durch Drucken, versuchen Sie, einen Drucker über lpinfo usw. zu finden, beenden Sie die Erfassung des ereignisbezogenen CUPSD-Protokolls von Schritt oben mit <Strg>+<C>.

Ereignisbezogenes cupsd-Protokoll (defekte Druckerwarteschlange wird von HPLIP unterstützt)

Leider protokollieren HPLIP-Bibliotheken nicht im Journal der CUPS-Unit. Wenn Ihre Druckerwarteschlange mit dem HPLIP-Treiber installiert ist (ihre Geräte-URI beginnt mit hp://), benötigen wir ein ereignisbezogenes Journalprotokoll.

Wie man mit der Erfassung von ereignisbezogenen Journalprotokollen beginnt

Bitte geben Sie im neuen Terminal/Terminal-Reiter Folgendes ein:

journalctl -f > journal_whole_log

Wie man eine ereignisbezogene Journalprotokollierung erhält

Nachdem Sie die Fehlerbedingung ausgelöst haben, die Sie zu diagnostizieren versuchen, z. B. durch Drucken, Ausführen eines HP-Skripts usw., beenden Sie die Erfassung des ereignisbezogenen Journalprotokolls aus dem Schritt oben mit <Strg>+<C>.

Debug-Protokollierung deaktivieren

Bitte fügen Sie cups_job_log für den problematischen Auftrag, cups_whole_log oder journal_log, falls Sie das gesamte cupsd-Protokoll während des problematischen Ereignisses erfasst haben, als Anhang zum Fehlerbericht hinzu.

Um die Debugging-Informationen zu deaktivieren, gehen Sie wie folgt vor:

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

Weitere Befehle für die Arbeit mit systemd-journald

Protokollmeldungen anzeigen mit:

journalctl -u cups -e

oder:

journalctl -u cups --since=...

Um Meldungen zu einer bestimmten Auftrags-ID herauszufiltern, verwenden Sie:

journalctl -u cups JID=...

(Die Tab-Vervollständigung zeigt Ihnen an, welche Auftrags-IDs Protokollmeldungen enthalten.)

Protokollierung von cups-browsed

Der cups-browsed-Daemon wurde in Fedora etwa mit Version cups-1.5 eingeführt. Er kann Bonjour-Broadcasts, CUPS-Broadcasts (veraltet) und LDAP-Server nach Druckern durchsuchen und lokale Warteschlangen für diese Drucker erstellen oder entfernen. Er kann zwar Broadcasts für lokale CUPS-Warteschlangen erstellen, diese Funktion ist jedoch als veraltet gekennzeichnet.

Um die Debug-Protokollierung zu aktivieren, müssen Sie

DebugLogging stderr

zu /etc/cups/cups-browsed.conf hinzu.

Die Protokolle sind nach einem Neustart von cups-browsed im Systemjournal verfügbar.

HPLIP-Skripte-Debug-Protokollierung

Die Python-Skripte von HPLIP (z.B. hp-setup, hp-clean, hp-scan) leiten ihre Debug-Protokollierung in den Standardfehlerdateideskriptor um und werden daher nicht im Journal protokolliert. Um die Debug-Protokollierung zu erhalten, führen Sie das Skript mit dem Parameter -ldebug aus, z.B.:

$ hp-setup -ldebug -i

und reproduzieren Sie das Problem. Kopieren Sie anschließend die Meldungen aus dem Terminal in die Datei hp_script_log. Bitte hängen Sie diese Datei auch an das Bugzilla-Ticket an.

Welche Marke und welche Modellbezeichnung hat mein Drucker?

Jeder Drucker hat eine modellspezifische Geräte-ID. Diese können Sie mit dem Befehl lpinfo herausfinden:

su -c "lpinfo -l -v"

Dieser Befehl startet jedes Backend im Erkennungsmodus, damit es die automatisch erkennbaren Geräte meldet. Es wird eine Reihe von Zeilenblöcken ausgegeben, die jeweils wie folgt aussehen:

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 =

Die Zeile, die diesen speziellen Modelltyp kennzeichnet, ist die lange Zeile, die mit "device-id =" beginnt (hier über drei Zeilen umgebrochen).

Falls Ihr Drucker nicht automatisch erkannt wird, können Sie die Geräte-ID möglicherweise trotzdem ermitteln, indem Sie das entsprechende Backend mit dem Hostnamen des Druckers als Argument ausführen. Die Backends usb, parallel, snmp und dnssd versuchen alle, die vom Drucker bereitgestellte Geräte-ID auszugeben.

$ /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"

Die Geräte-ID ist in diesem Fall (siehe backend(7)) das vorletzte Feld.

Welche Druckerwarteschlangen stehen mir zur Verfügung?

Die Druckerwarteschlangen auf Ihrem Rechner können permanent oder temporär sein. CUPS kann alle verfügbaren Druckerwarteschlangen im lokalen Netzwerk (permanente und temporäre Warteschlangen) wie folgt auflisten:

$ lpstat -e

Weitere Informationen zu permanenten Warteschlangen erhalten Sie folgendermaßen:

$ lpstat -t

Welchen Treiber verwende ich?

Die PPD-Datei der Druckerwarteschlange gibt Auskunft darüber, welcher Treiber verwendet wird. Mit folgendem Befehl können Sie den verwendeten Treiber ermitteln:

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

Sie können dies auch mithilfe der Anwendung system-config-printer herausfinden. Doppelklicken Sie auf das Symbol der Warteschlange und sehen Sie sich das Feld „Hersteller und Modell“ an.

Um die verfügbaren Treiber anzuzeigen, klicken Sie auf den Knopf Ändern… neben dem entsprechenden Feld. Es kann hilfreich sein, einen anderen Treiber auszuprobieren, um zu sehen, ob das Problem weiterhin besteht.

Modelle ohne Treiber

Die meisten Drucker, die seit 2010 auf den Markt gekommen sind, unterstützen AirPrint oder IPP Everywhere. Das bedeutet, dass sie nicht installiert werden müssen, um zu funktionieren – das Gerät wird von Avahi erkannt und die Druckfunktionen werden über das IPP-Protokoll kommuniziert. Es handelt sich im Prinzip um treiberlose Geräte. In Fedora gibt es zwei Lösungen, die IPP Everywhere implementieren:

CUPS-Modell 'everywhere'
driverless-Treiber von cups-filters

CUPS-Modell 'everywhere'

Es handelt sich um die CUPS-Implementierung des IPP Everywhere-Standards, die als spezielles Druckermodell verfügbar ist. Dieses Modell kommt zum Einsatz, wenn Sie die temporäre CUPS-Warteschlange für Ihr Gerät nutzen oder Ihr Gerät in der CUPS-Weboberfläche oder über lpadmin (mit der Option -m everywhere) als IPP Everywhere-Modell installieren.

Da die erstellte PPD-Datei von der IPP-Kommunikation mit dem Drucker abhängt, benötigen wir Informationen, die vom Gerät erfasst werden. Sie können dazu den Befehl ipptool verwenden:

$ ipptool --ippserver ipptool.attr <URI_Ihres_Druckers> get-printer-attributes.test

Hängen Sie die erstellte Datei ipptool.attr gegebenenfalls an das Bugzilla-Ticket an.

`driverless`-Treiber von cups-filters

Der spezielle Treiber cups-Filters dient zur Generierung von PPD-Dateien gemäß dem IPP Everywhere-Standard. Dieser Treiber wird verwendet, wenn Sie bei der Druckerinstallation das treiberlose Modell auswählen.

Wir benötigen auch die Ausgabe der Anfrage „get-printer-attributes“:

$ ipptool --ippserver ipptool.attr <URI_Ihres_Druckers> get-printer-attributes.test

und Debug-Protokolle des Treibers selbst, wenn dieser die PPD für Ihr Gerät generiert:

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

Hängen Sie gegebenenfalls alle erstellten Dateien an das Bugzilla-Ticket an.

Eingrenzen des Problems

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.

Anwendung

Versuchen Sie, aus einer anderen Anwendung zu drucken, um zu sehen, ob das Problem dadurch behoben wird oder ob es unabhängig von der Druckmethode auftritt. Versuchen Sie außerdem, das Dokument über die Befehlszeile mit lp zu drucken.

Dokumentenformat

Wenn Sie Probleme beim Drucken von PDF-Dateien haben, versuchen Sie, andere Dateitypen zu drucken, um festzustellen, ob das Problem generell beim Drucken auftritt oder nur bei PDF-Dateien. Versuchen Sie, die Datei in ein anderes Format zu konvertieren und diese Version zu drucken.

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

Filter manuell ausführen

Fortgeschrittene Benutzer können die CUPS-Filter manuell ausführen und die Datendatei bei jedem Konvertierungsschritt zwischen verschiedenen Formaten untersuchen. Hier ist ein Beispiel dafür für eine Gutenprint-Warteschlange namens „pqueue“ mit der CUPS-Testseite, die einen eigenen MIME-Typ hat: 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, get CUPS job log and in cups_job_log 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.

This filter pipeline is from cups-1.6. With cups < 1.6 you can see bannertops → pstops → pstoraster instead.

Nun können Sie Filter manuell ausführen:

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.

Treiber

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.

Zum Erfassen der USB-Kommunikation:

Ermitteln Sie die Busnummer, an der das USB-Gerät angeschlossen ist, z.B.:

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

      =

Starten Sie die USB-Paketerfassung:

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

wobei N die Busnummer ist.

Für Netzwerkdrucker stehen Ihnen möglicherweise verschiedene Protokolle zur Verfügung, die Sie ausprobieren können.

socket ist für HP JetDirect (üblicherweise Port 9100)
lpd ist für ältere UNIX-Druckfreigaben
smb ist für CIFS-Freigaben von Windows-Systemen
ipp steht für Geräte mit Internet Printing Protocol (IPP) und auch für andere CUPS-Server — Sie können den IPP-Datenverkehr mit tcpdump wie folgt erfassen (der Schnittstellenname kann von p4p1 abweichen):

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

bjnp steht für Canons proprietäres bjnp-Netzwerkprotokoll (üblicherweise Port 8611)

Konfigurationswerkzeug

Falls Ihr Problem die Konfiguration von Druckerwarteschlangen betrifft, versuchen Sie es mit einer der anderen Methoden. Es stehen vier zur Verfügung:

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
die Weboberfläche von CUPS, http://localhost:631/
die Befehlszeilenwerkzeuge lpadmin, lpoptions, cupsctl, cupsaccept, cupsenable usw.

Erfahrungsberichte

Es gibt einige typische Erfahrungsberichte beim Debuggen von Druckproblemen. Ich werde einige davon erwähnen und die Schritte zur Beschaffung der benötigten Informationen erläutern.