In den folgenden Abschnitten werden die am häufigsten auftretenden Hard- und Software-Probleme beim Drucken beschrieben und Wege zur Behebung oder Umgehung diese Probleme gezeigt.
Ein Drucker, der nur mit speziellen Steuersequenzen angesprochen werden kann, wird GDI-Drucker genannt. Diese Drucker funktionieren nur mit den Betriebssystemversionen, für die der Hersteller einen Treiber mitliefert. GDI ist eine von Microsoft entwickelte Programmierschnittstelle zur grafischen Darstellung. Das Problem ist nicht die Programmierschnittstelle, sondern dass die GDI-Drucker nur über die proprietäre Druckersprache des jeweiligen Druckermodells angesprochen werden können.
Es gibt Drucker, die zusätzlich zum GDI-Modus eine Standarddruckersprache verstehen, wozu der Drucker passend einzustellen oder umzuschalten ist. Für einige GDI-Drucker gibt es proprietäre Treiber vom Druckerhersteller. Der Nachteil proprietärer Druckertreiber ist, dass weder garantiert werden kann, dass diese mit dem aktuell installierten Drucksystem funktionieren, noch dass diese für die verschiedenen Hardwareplattformen funktionieren. Drucker, die eine Standarddruckersprache verstehen, sind dagegen weder von einer speziellen Drucksystem-Version noch von einer speziellen Hardwareplattform abhängig.
Es ist in der Regel kostengünstiger, einen unterstützten Drucker anzuschaffen, anstatt Zeit für die Anpassung eines proprietären Linux-Treibers aufzuwenden. Mit einem ordentlichen Drucker ist das Treiberproblem ein für alle Male gelöst. Nie wieder ist dann eine spezielle Treibersoftware zu installieren und unter Umständen speziell zu konfigurieren, und nie wieder müssen Treiber-Updates beschafft werden, wenn das Drucksystem weiterentwickelt wurde.
Wenn für einen PostScript-Drucker keine PPD-Datei im Paket manufacturer-PPDs geeignet ist, sollte es
möglich sein, die PPD-Datei von der Treiber-CD des Druckerherstellers zu
verwenden oder eine passende PPD-Datei von der Webseite des
Druckerherstellers herunterzuladen.
Wenn die PPD-Datei als Zip-Archiv (.zip) oder als selbstentpackendes
Zip-Archiv (.exe) vorliegt, können Sie es mit
unzip entpacken. Klären Sie zuerst die
Lizenzbedingungen der PPD-Datei. Dann testen Sie mit dem Programm
cupstestppd , ob die PPD-Datei der „Adobe
PostScript Printer Description File Format Specification, Version
4.3“ genügt. Wird „FAIL“ ausgegeben, dann
sind die Fehler in der PPD-Datei so schwerwiegend, dass größere Probleme
zu erwarten sind.
Die von cupstestppd angegebenen
Problemstellen sollten beseitigt werden.
Wenn notwendig, fragen Sie direkt
den Druckerhersteller nach einer geeigneten PPD-Datei.
Am sichersten funktioniert es, wenn der Drucker direkt an der ersten parallelen Schnittstelle angeschlossen ist und im BIOS für die parallele Schnittstelle folgende Einstellungen gesetzt sind:
IO-Adresse 378 (hexadezimal)
Interrupt ist nicht relevant
Modus Normal,
SPP oder
Output-Only
DMA wird nicht verwendet
Ist trotz dieser BIOS-Einstellungen der Drucker nicht über die erste
parallele Schnittstelle ansprechbar, muss die IO-Adresse entsprechend der
BIOS-Einstellung explizit in der Form 0x378 in
/etc/modprobe.conf eingetragen werden. Sind zwei
parallele Schnittstellen vorhanden, die auf die IO-Adressen
378 und 278 (hexadezimal) eingestellt
sind, dann sind diese in der Form 0x378,0x278
einzutragen.
Wenn der Interrupt 7 noch frei ist, dann
kann mit dem in Beispiel 12.1, „
/etc/modprobe.conf: Interrupt-Betrieb für die erste parallele Schnittstelle
“
gezeigten Eintrag der Interrupt-Betrieb
aktiviert werden. Bevor der Interrupt-Betrieb aktiviert wird, ist der Datei
/proc/interrupts zu entnehmen, welche Interrupts
bereits verwendet werden, wobei hier nur die Interrupts angezeigt werden,
die momentan in Gebrauch sind. Dies kann sich je nach aktiv benutzter
Hardware ändern. Der Interrupt für die parallele Schnittstelle darf nicht
anderweitig in Gebrauch sein. Im Zweifel ist der Polling-Betrieb mit
irq=none zu nehmen.
Schließen Sie den Drucker direkt am Rechner an. Konfigurieren Sie den Drucker zum Test als lokalen Drucker. Wenn es so funktioniert, sind Netzprobleme die Ursache.
Das TCP/IP-Netzwerk inklusive Namensauflösung muss ordnungsgemäß funktionieren.
Mit folgendem Kommando kann man testen, ob überhaupt eine TCP-Verbindung
zum lpd (Port 515) auf dem Rechner
host möglich ist:
netcat -z host 515 && echo ok || echo failed
Wenn keine Verbindung zum lpd möglich ist, dann läuft entweder der lpd nicht, oder grundlegende Netzwerkprobleme sind die Ursache.
Als Benutzer root kann man mit
folgendem Kommando einen (ggf. sehr langen) Statusbericht für die
Warteschlange queue auf dem (entfernten)
Rechner host abfragen, sofern der dortige lpd
läuft und Anfragen dorthin geschickt werden können:
echo -e "\004queue" \ | netcat -w 2 -p 722 host 515
Wenn keine Antwort vom lpd kommt, dann läuft
entweder der lpd nicht, oder grundlegende Netzwerkprobleme sind die
Ursache. Wenn eine Antwort vom lpd kommt, sollte
diese klären, warum auf der Warteschlange queue auf
dem Rechner host nicht gedruckt werden kann. Wenn Sie
eine Antwort wie in Beispiel 12.2, „Fehlermeldung vom lpd“ erhalten,
liegt das Problem beim entfernten lpd.
Mit folgendem Kommando kann man testen, ob es im Netzwerk einen
CUPS-Netzwerk-Server gibt, denn dieser sollte über den UDP Port
631 seine Warteschlangen standardmäßig
alle 30 Sekunden broadcasten:
netcat -u -l -p 631 & PID=$! ; sleep 40 ; kill $PID
Wenn ein CUPS-Netzwerk-Server broadcastet, sollte die Ausgabe wie in Beispiel 12.3, „Broadcast vom CUPS-Netzwerk-Server“ aussehen.
Mit folgendem Kommando testet man, ob überhaupt eine TCP-Verbindung zum
cupsd (Port 631) auf dem Rechner
host möglich ist:
netcat -z host 631 && echo ok || echo failed
Wenn keine Verbindung zum cupsd möglich ist, dann
läuft entweder der cupsd nicht, oder grundlegende
Netzwerkprobleme sind die Ursache. lpstat -h host -l
-t liefert einen (ggf. sehr langen) Statusbericht für alle
Warteschlangen auf dem Rechner host, sofern
der dortige cupsd läuft und Anfragen dorthin
geschickt werden können.
Damit kann man testen, ob die Warteschlange
queue auf dem Rechner
host einen Druckauftrag annimmt, wobei der
Druckauftrag hier aus einem einzelnen Carriage-Return-Zeichen besteht
— das heißt hierbei wird nur getestet, aber normalerweise
sollte nichts gedruckt werden — und wenn, dann nur ein leeres
Blatt.
echo -en "\r" \ | lp -d queue -h host
Es gibt mitunter Probleme mit dem Druckerspooler, der in einer Printserver-Box läuft, sobald ein höheres Druckaufkommen vorliegt. Da es am Druckerspooler in der Printserver-Box liegt, kann man das nicht ändern. Man kann aber den Druckerspooler in der Printserver-Box umgehen, indem man den an der Printserver-Box angeschlossenen Drucker direkt via TCP-Socket anspricht; vgl. Abschnitt 12.5.2, „Netzwerkdrucker“.
Dadurch arbeitet die Printserver-Box nur noch als Umwandler zwischen den
verschiedenen Formen der Datenübertragung (TCP/IP-Netzwerk und lokaler
Druckeranschluss). Dazu muss der entsprechende TCP-Port auf der
Printserver-Box bekannt sein. Bei angeschlossenem und eingeschaltetem
Drucker an der Printserver-Box kann dieser TCP-Port normalerweise einige
Zeit nach dem Einschalten der Printserver-Box mit dem Programm
nmap aus dem Paket nmap ermittelt
werden. So liefert nmap
IP-address bei einer
Printserver-Box beispielsweise:
Port State Service 23/tcp open telnet 80/tcp open http 515/tcp open printer 631/tcp open cups 9100/tcp open jetdirect
Diese Ausgabe bedeutet, dass der über den Port 9100
an der Printserver-Box angeschlossene Drucker via TCP-Socket ansprechbar
ist. Standardmäßig prüft nmap nur eine gewisse Liste
von allgemein bekannten Ports, die in
/usr/share/nmap/nmap-services verzeichnet sind. Um
alle möglichen Ports zu überprüfen, verwenden Sie den Befehl:
nmap
-p from_port-to_port IP-address
(das kann dann etwas dauern) — vergleichen Sie dazu die Manualpage
man nmap.
Mit Befehlen der Art
echo -en "\rHello\r\f" | netcat -w 1 IP-address port cat file | netcat -w 1 IP-address port
können Zeichenfolgen oder Dateien direkt an den betreffenden Port geschickt werden, um zu testen, ob der Drucker über diesen Port ansprechbar ist.
Für das Drucksystem ist der Druckauftrag dann komplett abgearbeitet, wenn das CUPS-Backend mit der Datenübertragung zum Empfänger (Drucker) fertig ist. Wenn danach die weitere Verarbeitung beim Empfänger scheitert (beispielsweise wenn der Drucker die druckerspezifischen Daten nicht zu Papier bringen kann), merkt das Drucksystem davon nichts. Wenn der Drucker die druckerspezifischen Daten nicht zu Papier bringen kann, sollte eine andere PPD-Datei gewählt werden, die besser zum Drucker passt.
Wenn die Datenübertragung zum Empfänger nach mehrere Versuchen endgültig
scheitert, meldet das CUPS-Backend (beispielsweise usb
oder socket), einen Fehler an das Drucksystem (an den
cupsd). Das Backend entscheidet, ob und wieviele
Versuche sinnvoll sind, bis es die Datenübertragung als unmöglich meldet.
Da weitere Versuche somit sinnlos sind, wird das Ausdrucken für die
betroffene Warteschlange vom cupsd abgeschaltet. Nachdem
die Ursache des Problems behoben wurde, muss der Systemverwalter mit
/usr/bin/enable das Ausdrucken wieder aktivieren.
Wenn ein CUPS-Netzwerk-Server seine Warteschlangen via Browsing den Client-Rechnern mitteilt und auf den Client-Rechnern läuft dazu passend ein lokaler cupsd, dann nimmt der cupsd des Clients die Druckaufträge von den Anwendungsprogrammen an und schickt sie sofort weiter an den cupsd des Servers. Wenn ein cupsd einen Druckauftrag annimmt, bekommt er immer eine neue Jobnummer. Daher ist die Jobnummer auf dem Client-Rechner eine andere als auf dem Server. Da ein Druckauftrag sofort weitergeschickt wird, kann er normalerweise nicht mit der Jobnummer des Client-Rechners gelöscht werden, denn für den cupsd des Clients ist der Druckauftrag mit der erfolgreichen Weiterleitung an den cupsd des Servers komplett abgearbeitet.
Um den Druckauftrag auf dem Server zu löschen, ist mit einem Befehl wie lpstat -h print-server -o die Jobnummer auf dem Server zu ermitteln, sofern der Server den Druckauftrag nicht auch schon abgearbeitet (d. h. an den Drucker geschickt) hat. Mit dieser Jobnummer kann der Druckauftrag auf dem Server gelöscht werden:
cancel -h print-server Warteschlange-Jobnnummer
Druckaufträge bleiben in den Warteschlangen erhalten und werden ggf. von Anfang an erneut gedruckt, wenn Sie während eines Druckvorgangs den Drucker aus- und einschalten oder den Rechner herunterfahren und neu starten. Einen fehlerhaften Druckauftrag müssen Sie mit dem cancel Befehl aus der Warteschlange entfernen.
Ist ein Druckauftrag fehlerhaft oder kommt es zu einer Störung in der Kommunikation zwischen Rechner und Drucker, kann der Drucker mit den gesendeten Daten nichts Sinnvolles anfangen. Es werden lediglich Unmengen Papier mit sinnlosen Zeichen bedruckt. Um dieses Problem zu beheben, gehen Sie wie folgt vor:
Entnehmen Sie zuerst alles Papier bei Tintenstrahldruckern bzw. öffnen Sie die Papierschächte bei Laserdruckern, damit das Drucken aufhört. Bei hochwertigen Druckern gibt es am Drucker einen Knopf, den aktuellen Ausdruck abzubrechen.
Da der Druckauftrag erst dann aus der Warteschlange entfernt wird,
nachdem er komplett an den Drucker geschickt wurde, wird er meist noch in
der Warteschlange stehen. Prüfen Sie mit lpstat -o
(bzw. mit lpstat -h print-server
-o) aus welcher Warteschlange gerade gedruckt wird und löschen
Sie mit cancel
Warteschlange-Jobnummer
(bzw. mit cancel -h
print-server
Warteschlange-Jobnummer)
den Druckauftrag.
Eventuell werden noch einige Daten an den Drucker übertragen, obwohl der Druckauftrag aus der Warteschlange gelöscht ist. Prüfen Sie ob noch ein CUPS-Backend Prozess für die betreffende Warteschlange läuft und beenden Sie diesen. z. B. können für einen Drucker an der parallelen Schnittstelle mit dem Befehl fuser -k /dev/lp0 alle Prozesse beendet werden, die noch auf den Drucker (die parallele Schnittstelle) zugreifen.
Setzen Sie den Drucker komplett zurück, indem Sie ihn einige Zeit vom Stromnetz trennen. Danach legen Sie das Papier wieder ein und schalten den Drucker an.
Zur Problemanalyse im CUPS-Drucksystem empfiehlt sich folgendes Vorgehen:
Setzen Sie LogLevel debug in
/etc/cups/cupsd.conf.
Stoppen Sie den cupsd.
Bewegen Sie /var/log/cups/error_log* weg
damit Sie nicht in zu großen Logdateien suchen müssen.
Starten Sie den cupsd.
Versuchen Sie erneut, was zu dem Problem geführt hat.
Nun finden sich viele Meldungen in
/var/log/cups/error_log*,
die zur Ursachenermittlung nützlich sind.
Lösungen zu vielen spezifische Probleme werden in der Supportdatenbank vorgestellt. Falls Sie Schwierigkeiten mit dem Drucker haben, lesen Sie die SDB-Artikel Drucker einrichten und Drucker einrichten ab SUSE LINUX 9.2, die Sie finden können, indem Sie das Stichwort „Drucker“ eingeben.