Das Symptom
Du klickst auf Drucken. Der Dialog schließt sich zufrieden. Und dann: nichts. Kein
Blatt, kein Geräusch, keine Fehlermeldung — und, das ist der eigentliche Affront,
auch kein Auftrag in der Warteschlange. Dort ist es so leer, als hättest du nie
gedruckt. Kein Fehler, kein Hinweis, keine Spur. Nur ein Dokument, das sich
offenbar in Luft aufgelöst hat, und ein Drucker, der so tut, als hätte er von der
ganzen Sache nie gehört.
Die „Layer 8“-Wahrheit
Ein Druckauftrag durchläuft eine Kette von Übergaben, und keine Stelle in dieser
Kette hält sich für zuständig. Die Anwendung reicht das Dokument an die
Warteschlange und ist damit fertig. Die Warteschlange reicht es an den Anschluss
und ist damit fertig. Der Anschluss schiebt Daten in ein Kabel oder ins Netz und
ist damit ebenfalls fertig. Ob am anderen Ende ein Blatt herauskommt, weiß von
diesen dreien niemand — und keiner von ihnen hat je behauptet, es zu wissen. Ein
Fehler entsteht dort, wo jemand eine Rückmeldung erwartet. Hier erwartet niemand
eine.
Deshalb ist das spurlose Verschwinden kein Ausnahmezustand, sondern der
dokumentierte Normalfall. Microsoft schreibt es ohne jede Ironie hin: Wenn das
Drucken korrekt funktioniert, werden die Dateien im Spool-Ordner gelöscht, sobald
die Aufträge gedruckt sind. Ein Auftrag, der aus der Warteschlange verschwindet,
sieht also exakt so aus wie ein Auftrag, der erfolgreich war. Der Unterschied
zwischen Erfolg und Totalausfall ist an dieser Stelle: kein Unterschied.
Und dann gibt es noch die Erklärung, die niemand hören will und die Apple in
seinem Handbuch trotzdem als Erstes nennt: Der Auftrag ist nicht weg, er ist
woanders. Auf dem PDF-Erzeuger. Auf dem Faxtreiber. Auf der Warteschlange des
Druckers, der seit zwei Umzügen nicht mehr existiert und den trotzdem niemand
gelöscht hat. Bevor du also anfängst, Protokolle zu lesen, sieh in den anderen
Warteschlangen nach. Die Wahrscheinlichkeit, dass dein Dokument dort geduldig
wartet, ist unangenehm hoch — und sie ist der Grund, warum diese Kategorie einen
eigenen Schweregrad hat.
Die echte, verifizierte Lösung
1000 % faktenbasiert. Jeder Befehl ist real, jeder Pfad existiert. Schritt für Schritt:
1.Erst nachsehen, wohin überhaupt gedruckt wurde
Bevor man Protokolle durchsucht, klärt man das Ziel. Unter Linux und macOS zeigt CUPS das aktuelle Standardziel direkt an — die Handbuchseite beschreibt diese Option als Anzeige des aktuellen Standardziels. Unter Windows steht der Standarddrucker in den Einstellungen unter Bluetooth und Geräte bei Drucker und Scanner. Wer auf einem PDF-Erzeuger oder einer verwaisten Warteschlange gelandet ist, hat sein Blatt bereits gefunden.
lpstat -d
2.Die erledigten Aufträge abfragen, nicht nur die offenen
Die Warteschlangenanzeige zeigt standardmäßig nur, was noch aussteht. Die CUPS-Handbuchseite nennt dafür einen eigenen Schalter, mit dem sich auswählen lässt, welche Aufträge gezeigt werden — alle, erfolgreiche, abgeschlossene oder die nicht abgeschlossenen als Standard. Wichtig: Dieser Schalter muss vor der Auftragsliste stehen, sonst wird er ignoriert. Taucht der Auftrag hier als abgeschlossen auf, ist er nicht verschwunden, sondern gedruckt worden — irgendwo.
lpstat -W completed -o
3.Unter Windows in den Spool-Ordner schauen
Microsoft beschreibt den Ordner als Prüfstelle: Wenn das Drucken korrekt läuft, werden die Dateien dort beim Drucken gelöscht. Liegen dort alte Dateien herum, ist etwas hängengeblieben; liegt dort nichts und es kam trotzdem kein Blatt, war der Auftrag nie da. Der Standardpfad steht in der Dokumentation, der tatsächliche notfalls in der Registrierung unter dem Wert DefaultSpoolDirectory.
%systemroot%\System32\spool\PRINTERS
4.Den Drucker anhalten und noch einmal drucken
Der schönste Trick aus der Microsoft-Dokumentation und der einzige verlässliche Test, ob der Auftrag überhaupt entsteht: Den Drucker anhalten. Der Auftrag wird dann zwar in die Warteschlange geschrieben, aber nicht gedruckt — man kann ihn also in Ruhe ansehen, statt ihm hinterherzusehen. Erscheint er beim angehaltenen Drucker nicht, liegt das Problem vor der Warteschlange, also in der Anwendung oder im Treiber.
5.Unter Linux das Protokoll mitlesen
CUPS führt drei Protokolle. In error_log steht der Ablauf, in page_log laut Dokumentation bei jedem erfolgreichen Druck ein neuer Eintrag, in access_log die Serveraktivität. Wer den Auftrag beim Verschwinden beobachten will, lässt das Fehlerprotokoll mitlaufen und druckt dann.
sudo tail -n 100 -f /var/log/cups/error_log
6.Wenn nötig, die Ausführlichkeit hochdrehen
Bleibt das Protokoll wortkarg, schaltet man die Fehlersuchstufe ein. Dazu in /etc/cups/cupsd.conf die Zeile LogLevel debug setzen und den Dienst neu starten. Danach denselben Auftrag noch einmal schicken und mitlesen. Die Zeilen sind vorne gekennzeichnet — D steht für Debug, E für Error, I für Information.
LogLevel debug
7.Im Zweifel eine frische Warteschlange anlegen
Führt nichts zum Ziel, empfiehlt Microsoft ausdrücklich, für das Gerät eine neue Druckwarteschlange anzulegen und über diese zu drucken. Apple sagt für denselben Fall dasselbe: Ist die Warteschlange beschädigt, löscht man sie und richtet den Drucker neu ein. Eine alte Warteschlange mit halb entferntem Treiber ist kein Vermögenswert, den man erhalten müsste.