CUPS – Bekannte Probleme

cups-browsed verliert manchmal die Verbindung zum Druckserver (insbesondere bei älteren Versionen wie cups-1.4.2), wenn der Laptop die Netzwerkverbindung ändert (z.B. Wechsel des WLAN-Netzwerks oder nach dem Aufwachen aus einem Energiesparmodus). Sie können das Drucken wiederaufnehmen, indem Sie Ihre Druckaufträge abbrechen und cups-browsed neu starten mit

Das Erstellen lokaler Druckerwarteschlangen dauert bei manchen Druckern mit großen PPD-Dateien lange, was zu einer Zeitüberschreitung der HTTP-Verbindung und einer Endlosschleife beim Erstellen lokaler Druckerwarteschlangen führt. Um dieses Problem zu beheben, fügen Sie bitte

in /etc/cups/cups-browsed.conf`ein, wobei `N die Anzahl der Sekunden angibt, nach denen die Verbindung getrennt wird. Starten Sie anschließend den cups-browsed-Dienst neu. Diese Option ist ab Fedora 27 verfügbar.

Dieses Problem hängt mit fernen CUPS-Warteschlangen zusammen, die von älteren CUPS-Versionen (üblicherweise unter cups-1.5, z.B. RHEL 6) bereitgestellt werden. Cups-browsed erstellt standardmäßig lokale Druckerwarteschlangen, die nach der DNS-SD-ID des Druckers benannt werden. Die Benennung nach fernen CUPS-Warteschlangen kann durch Hinzufügen folgender Zeile:

in /etc/cups/cups-browsed.conf wieder aktiviert und der cups-browsed-Dienst neu gestartet werden.

Wenn Ihr Drucker (aus Ihrer Sicht) sehr lange zum Drucken benötigt oder gar nicht druckt (einige Xerox-Drucker haben solche Probleme mit dem gs-Renderer und funktionieren daher erst wieder mit dem pdftops-Renderer), können Sie versuchen, den standardmäßigen PostScript-Renderer zu ändern. Der Standard-Renderer in Fedora ist für die meisten Drucker der gs-Filter von Ghostscript. Für Brother-, Minolta- und Konica-Minolta-Drucker gibt es jedoch den pdftops-Filter von Poppler – diese Konfiguration wird als Hybrid bezeichnet.

Weitere verfügbare Renderer-Setups sind gs (von Ghostscript), pdftops und pdftocairo (von Poppler), mupdf (von mupdf) und acroread (von Adobe Reader, nicht in den offiziellen Fedora-Repositories). Anschließend können Sie einen anderen Standard-Renderer für Ihre Druckerwarteschlange wie folgt festlegen:

ACHTUNG: Die meisten Probleme mit langsamem Drucken werden durch PDF-Erstellungsprogramme verursacht, die fehlerhafte PDF-Dateien erzeugen – und genau diese fehlerhafte Datei ist meist die Ursache des Problems. Zusammenfassend lässt sich sagen, dass langsames Drucken auch bei anderen PDF-Dateien auftreten kann. Die Entscheidung liegt dann beim Benutzer: Möchte er schnell drucken und gegebenenfalls den Standard-Renderer ändern, oder ist die geringe Druckgeschwindigkeit für ihn kein so gravierendes Problem?

Dieser Fehler betrifft alle Anwendungen, die den GTK-Druckdialog verwenden. Der GTK-Dialog bezieht Informationen über verfügbare Warteschlangen aus zwei Quellen: mDNS-Nachrichten von Avahi und CUPS. Diese Dummy-/Duplikat-Druckwarteschlange wird vom GTK-Dialog anhand der Avahi-Nachrichten erstellt, existiert aber nicht in CUPS, da sie dort nicht angelegt wurde. GTK verhält sich jedoch so, als ob sie in CUPS vorhanden wäre. Jedes Mal, wenn ein Benutzer drucken möchte, sendet GTK eine Anfrage an CUPS für diese Warteschlange, die jedoch von CUPS verworfen wird, da die Warteschlange nicht existiert.

Die Funktion, die GTK hier implementieren möchte, heißt CUPS-Temporärwarteschlangen. Die GTK-Entwickler arbeiten aktuell an einer Sofortlösung (siehe das Bugzilla-Ticket). Zukünftig soll das Backend cpdb-backend-cups in GTK verwendet werden, aktuell konzentrieren wir uns jedoch auf die Zwischenlösung.

CUPS hat manchmal Probleme mit bestimmten Arten von FQDNs – das bedeutet, dass CUPS einen FQDN nicht als gültigen Hostnamen erkennt, wenn Sie ihn in der Direktive BrowsePoll in der Datei /etc/cups/cups-browsed.conf verwenden. Das Problem lässt sich durch Hinzufügen folgender Zeile beheben:

in /etc/cups/client.conf und den CUPS-Dienst neu starten.

Eine ähnliche Situation kann bei Scannern auftreten, die sane-airscan unterstützen. Einige Geräte deklarieren über Protokolle – z. B. IPP 2.0+, WSD, eSCL – weniger Optionen, die treiberlose Lösungen unterstützen als klassische Treiber. Normalerweise liegt das Problem an der Geräte-Firmware. Dies lässt sich überprüfen, indem man die Ausgabe des folgenden Befehls prüft:

Der Befehl führt dieselbe IPP-Anfrage aus, die auch beim Erscheinen einer temporären Druckwarteschlange im Druckdialog oder bei der permanenten Installation der Warteschlange erfolgt. Die Druckeroptionen werden anhand der IPP-Antwort auf diese Anfrage festgelegt. Fehlt die Option in der Antwort, kann CUPS diese Druckeroption nicht generieren. Versuchen Sie in diesem Fall, die Geräte-Firmware zu aktualisieren, das Problem dem Gerätehersteller zu melden und es auf Bugzilla mit den Protokollen zu veröffentlichen.

Fedora 33 hat die Anforderungen an Kryptorichtlinien erhöht, daher sind SSL- und ältere TLS-Protokolle systemweit deaktiviert. Diese Änderung verhindert das Drucken über IPPS auf Geräten, die neuere Protokolle nicht unterstützen. Sie können die Unterstützung für ältere Kryptosysteme in den Kryptorichtlinien wie folgt wiederherstellen:

Die Richtlinienänderung hat vorübergehend Auswirkungen auf die von cups-browsed gefundenen Geräte, da der Daemon IPPS-URIs bevorzugt, wenn diese vom Drucker/Server als verfügbar gemeldet werden.

Manchmal funktioniert die PDF-Unterstützung bei bestimmten Druckern nicht richtig, was zu fehlerhaften Ergebnissen führen kann (z.B. werden diakritische Zeichen wie š oder ž als kleine Rechtecke gedruckt).

Wenn der Druckertreiber auch Rasterisierung unterstützt, könnte man den Drucker mit dem IPP Everywhere-Treiber neu installieren (der standardmäßige treiberlose Treiber funktioniert nicht mit der Option „Drucken als Raster“):

Man kann nun die Rasterisierung für einen neuen Druckauftrag erzwingen mit:

oder legen Sie die Rasterisierung für diesen Drucker standardmäßig fest mit:

Beachten Sie jedoch, dass einige IPP-Funktionen bei Rasterisierung nicht zur Verfügung stehen, z.B. Endbearbeitungen. Die beste Lösung für solche Probleme ist, sich an den Hersteller Ihres Druckers zu wenden und ihn zu bitten, die PDF-Unterstützung des Druckers in der Firmware zu aktualisieren.

Dieser häufige Fehler wird meist durch externe Ursachen (Serverausfall, Netzwerkausfall) hervorgerufen, wenn wget versucht, ein Plugin herunterzuladen, aber nur eine Fehlermeldung zurückgibt. Er hängt mit folgender Meldung zusammen:

Dabei ist N der Rückgabewert von wget (siehe man wget), das zum Herunterladen proprietärer Plugins verwendet wird. Die Lösungen für dieses Problem können variieren: Sie können warten, bis die Server wieder erreichbar sind, oder versuchen, das Plugin manuell von http://www.openprinting.org/download/printdriver/auxfiles/HP/plugins/ herunterzuladen (wählen Sie dazu bei hp-setup oder hp-plugin die Option „Select and install an existing local copy of the plug-in file“).

Dieser Fehler kann auftreten, wenn hplip von der HP-Website installiert wurde oder wenn es sich bei den Abhängigkeiten um gemischte Python2- und Python3-Pakete handelt oder diese über pip installiert wurden. Das Problem lässt sich beheben, indem alle hplip-Pakete (hplip, hplip-gui, hplip-libs, hplip-common, libsane-hpiao) entfernt und anschließend aus den jeweiligen Paketquellen neu installiert werden.

GUI-Tools und GUI-Komponenten von HP-Befehlen wurden in das Teilpaket hplip-gui ausgelagert, da das Hauptpaket auch ohne GUI funktioniert und dadurch kleiner ist. Dies hat zur Folge, dass HP-Befehle entweder mit der Option -i für den interaktiven Modus ausgeführt oder das Unterpaket hplip-gui installiert werden muss.

Werkzeuge, die in der Befehlszeile mit der Option -i ausgeführt werden müssen oder für die grafische Oberfläche die Installation von hplip-gui erfordern:

Werkzeuge, die in hplip-gui verfügbar sind:

Einige HP-Drucker funktionieren nicht einwandfrei mit den von CUPS bereitgestellten URIs (dnssd, usb, ipp) oder benötigen ein proprietäres HP-Plugin, das aus Lizenzgründen unter Fedora nicht verfügbar ist. Versuchen Sie für solche Drucker Folgendes:

für den interaktiven Modus, oder:

für den Grafikmodus. Dieser Befehl installiert HP Drucker und Scanner. Falls Ihr HP Drucker/Scanner nicht erkannt wird, nicht oder nicht korrekt druckt, versuchen Sie bitte, ihn mit dem Befehl hp-setup zu installieren. Sollte dies nicht helfen, erstellen Sie bitte einen Bugzilla-Eintrag, fügen Sie die Ausgabe von hp-setup bei und erwähnen Sie, dass Sie den Befehl hp-setup bereits verwendet haben.

Geräte, die ein Plugin benötigen, können nach einer Aktualisierung auf eine neuere HPLIP-Version nicht mehr funktionieren. Dies liegt an der Überprüfung der Plugin-Version im Code. Diese Überprüfung ist notwendig, um Inkonsistenzen zu vermeiden, die entstehen, wenn neue Funktionen in der Open-Source-Software HPLIP neue proprietäre Bibliotheken des Plugins benötigen. Um Ihren Drucker wieder zum Laufen zu bringen, laden Sie das Plugin einfach erneut herunter und installieren Sie es mit folgendem Befehl:

Geräte, die ein HP-Plugin aus dem geschlossenen Quellcode benötigen, müssen dieses standardmäßig bei jedem Start/Neustart des PCs neu installieren. Das HP-Skript installiert die Plugins in schreibgeschützten Verzeichnissen, sodass sie beim Starten/Neustart von Fedora entfernt werden. Als Alternative können Sie prüfen, ob Ihr Gerät treiberloses Drucken und Scannen unterstützt, und das Paket hplip-plugin von RPMFusion verwenden oder das Plugin bei jedem Druckvorgang neu installieren.

Der ipp-usb-Daemon hält den USB-Anschluss des IPP-over-USB-Geräts für jede mögliche zukünftige IPP-Kommunikation geöffnet, wodurch der Anschluss für andere Treiber (z. B. HPLIP, gutenprint, sane-backends…​) blockiert wird.

Bei Druckern besteht die Lösung darin, die Warteschlange mit dem Treiber zu deinstallieren, und zwar folgendermaßen:

und verwenden Sie die von ipp-usb bereitgestellte (siehe CUPS temporäre Warteschlange oder installieren Sie eine permanente - die Standard-Geräte-URI ist ipp://localhost:60000/ipp/print).

Bei Scannern erkennt sane-airscan das virtuelle Gerät automatisch über ipp-usb, sofern das Gerät WSD- oder eSCL-Protokolle unterstützt. Wurde der Scanner jedoch zuvor von klassischen Scannertreibern wie hplip oder sane-backends unterstützt und wird nun von ipp-usb aufgrund der Unterstützung des treiberlosen IPP-over-USB-Standards beansprucht, wird der alte Scanner zwar weiterhin angezeigt, kann aber aufgrund eines USB-Konflikts nicht mehr scannen. Dies liegt daran, dass klassische Backends alle Geräte auflisten, die sie über USB-Schnittstellen finden und der Beschreibung des Backends entsprechen. Die Backends prüfen jedoch erst beim Öffnen des USB-Ports für den Scanvorgang, ob tatsächlich eine Kommunikation mit dem Gerät möglich ist. Dies stellt ein Problem für Scananwendungen dar, die den vorherigen Scanner automatisch als Standardgerät auswählen (z. B. Simple Scan). Benutzer müssen vor dem Scannen einen treiberlosen Scanner aus der Liste der verfügbaren Scanner auswählen.

Das von klassischen SANE-Backends erkannte Scannergerät kann deaktiviert werden, indem der entsprechende Eintrag in der Backend-Konfigurationsdatei unter /etc/sane.d oder der gesamte Backend-Name in /etc/sane.d/dll.conf//etc/sane.d/dll.d auskommentiert wird. Beispiel: Die Canon MF440-Serie wird von den Backends pixma und airscan gemeldet, aber nur airscan funktioniert, da es ein Backend ist, das auf dem Netzwerkprotokoll basiert, und die USB-Schnittstelle von ipp-usb belegt wird. Daher deaktivieren wir das Backend pixma, indem wir die entsprechende Zeile in /etc/sane.d/dll.conf auskommentieren:

Falls das von ipp-usb erstellte Gerät nicht Ihren Anforderungen entspricht (die von Ihnen verwendeten Optionen fehlen, das Gerät funktioniert nicht, obwohl es IPP-over-USB unterstützt), melden Sie das Problem bitte zusammen mit den Protokollen aus dem Verzeichnis /var/log/ipp-usb/ unter bugzilla. ipp-usb selbst unterstützt sogenannte Quirks, mit denen Sie den Daemon so konfigurieren können, dass er Ihr Gerät ignoriert, und Sie wieder auf einen klassischen Treiber zurückgreifen können. Die Schritte sind wie folgt:

Eine ähnliche Situation kann bei everywhere- oder driverless-Druckern auftreten. Einige Geräte deklarieren über Protokolle – z. B. IPP 2.0+, WSD, eSCL – weniger Optionen, die treiberlose Lösungen unterstützen als klassische Treiber. In der Regel liegt das Problem an der Geräte-Firmware, was sich in den Debug-Protokollen von sane-airscan und im Netzwerkverkehr überprüfen lässt. Die Lösung besteht darin, die Geräte-Firmware zu aktualisieren, das Problem dem Gerätehersteller zu melden und es zusammen mit den Protokollen in Bugzilla einzureichen.