CUPS – Come eseguire il debug dei problemi di stampa

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

Se si riscontrano problemi con la stampa, consultare la pagina bug comuni prima di segnalare un bug. Se il problema riscontrato non è elencato o nessuna delle soluzioni alternative sembra essere d’aiuto, si prega di considerare di segnalare un bug per aiutarci a far funzionare meglio Fedora sul proprio hardware.

Identificare l’area del problema

I problemi di stampa possono essere piuttosto complessi e può essere richiesta una cooperazione attiva o molti dati dal segnalatore al manutentore per aiutarlo a comprendere e (se non si tratta di un problema specifico dell’hardware) riprodurre il problema, quindi si prega di avere pazienza e di provare a circoscrivere il problema il più possibile per i manutentori.

Ci possono essere:

problemi nel vedere o connettersi alla stampante (possono essere problemi del backend di CUPS, di Avahi, di libusb, di cups-browsed),
problemi di accessibilità (configurazione corretta/errata in cupsd.conf o sua errata interpretazione da parte del demone cupsd, cattiva cooperazione con NIS, SSSD…),
stampa con l’aiuto di Samba (problemi con il backend smb, che è parte di Samba) o con Samba autenticato tramite Kerberos (samba_krb5_printing),
problemi con i filtri utilizzati durante la conversione del documento nel formato supportato dalla stampante, che influenzano come o se il documento verrà stampato (problemi con i filtri - pdftops, pdftopdf, pstops, bannertopdf ecc. - o problemi con i binari o le librerie che i filtri utilizzano - libgs, qpdf, poppler…),
problemi con i file Postscript Printer Description, che sono un vecchio modo di definire le capacità delle stampanti come i formati di pagina supportati, i bordi, ecc…

Senza menzionare possibili limitazioni o problemi nel firmware o nell’hardware della stampante stessa, quindi ogni tipo di dato o di circoscrizione del problema è benvenuto.

Il modo migliore per iniziare è allegare i file con i log descritti di seguito.

Registrazione di CUPS

Tutta la registrazione di CUPS è reindirizzata al journal di default a partire da Fedora 28 (prima di Fedora 28 c’era un reindirizzamento predefinito di error_log al journal).

È necessario definire due modi diversi per catturare i log completi di CUPS legati a un incidente: uno se la coda di stampa problematica non è fornita da HPLIP e l’altro se lo è. Differiscono nell’opzione di filtro di journald: se si utilizza una coda non-HPLIP per il debug, è sufficiente raccogliere i log dall’unità systemd di CUPS (con '-u cups'), perché tutti i messaggi di errore vengono reindirizzati correttamente alla registrazione dell’unità systemd di CUPS e sono accessibili nell’output dopo il filtraggio per unità. Le librerie HPLIP non sono implementate per fare lo stesso (l’upstream non risponde per accettare una potenziale correzione nel progetto e il problema non è abbastanza critico da mantenere una patch downstream per sempre), quindi i loro messaggi non sono contrassegnati per l’unità systemd di CUPS e vengono filtrati dopo aver chiamato journald con '-u cups'. Per tali code è richiesto il log di journald senza filtri.

Il log di journald legato all’incidente senza filtri è richiesto solo per le code di stampa HPLIP (il cui URI del dispositivo inizia con hp://) ed è sconsigliato per le altre code, perché può essere difficile da leggere in casi più estesi. Si prega di allegare il log di journald legato all’incidente solo quando è necessario.

Posizione della registrazione di CUPS

La registrazione di CUPS si trova di default nel journal di sistema, ma la registrazione su file può essere impostata in /etc/cups/cups-files.conf con la direttiva ErrorLog. Se si desidera modificare le impostazioni predefinite, il nome del file di log è irrilevante, ma si consiglia di inserire il file nel percorso /var/log/cups, altrimenti SELinux bloccherà l’accesso a cupsd.

Impostare la registrazione su un file ha i seguenti svantaggi (senza ulteriori operazioni):

impossibilità di ottenere solo i log connessi a un lavoro senza concatenare più comandi
impossibilità di ottenere i log per un intervallo di tempo specificato senza concatenare più comandi

Per catturare i log legati a un incidente, si può usare tail -f, ad esempio:

tail -f /var/log/cups/error_log

Abilitare la registrazione di debug di CUPS

Abilitare le informazioni di debug complete con:

$ cupsctl LogLevel=debug2

Log dei lavori di CUPS

Se il problema si manifesta quando si invia un documento in stampa o si tenta di farlo, catturare i log per questo lavoro. Se il log del lavoro è disponibile, il suo allegato è RICHIESTO.

Preparare CUPS per la registrazione dei lavori

Per poter visualizzare il log di un lavoro specifico, attivare:

PreserveJobFiles Yes

nel proprio file /etc/cups/cupsd.conf e riavviare il servizio CUPS. Non dimenticare di rimuovere la riga una volta terminato il debug. lpstat -W all sembra essere vuoto dopo la stampa se non si abilita la direttiva.

Ottenere il log di un lavoro per un ID specifico

Per catturare il log di un lavoro è necessario conoscere l’ID del lavoro (JID) - è il numero dopo il trattino in un ID di richiesta:

Un ID di richiesta si presenta così:

<nome_coda_stampa>-<JID>

e può essere visualizzato nel terminale se si invia un documento in stampa con il comando lp:

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

O quando si elencano i lavori (vedere man lpstat) - il lavoro più recente è alla fine:

$ lpstat -W all
...
<nome_coda_stampa>-<JID>           <utente>           1024   Mer 11 Gen 2017 17:52:19 CET

È possibile ottenere automaticamente i log dell’ultimo lavoro (se si ha awk installato e lpstat -W all restituisce dei lavori) con:

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

O manualmente, se si è trovato il JID da soli:

journalctl -u cups JID=<JID> > cups_job_log

Log di cupsd legato all’incidente (la coda di stampa problematica non è supportata da HPLIP)

A volte non è possibile associare l’errore a un lavoro di stampa specifico, quindi il log del lavoro è inefficace. È necessario un log di cupsd legato all’incidente.

Come avviare la cattura della registrazione di cupsd legata all’incidente

In un nuovo terminale o scheda del terminale, eseguire:

journalctl -f -u cups > cups_whole_log

Come ottenere la registrazione di cupsd legata all’incidente

Dopo aver attivato la condizione di errore che si sta cercando di diagnosticare, ad esempio stampando qualcosa, cercando di trovare una stampante tramite lpinfo ecc., si termina la cattura del log di cupsd legato all’incidente dal passaggio precedente con <ctrl>+<c>.

Log di cupsd legato all’incidente (la coda di stampa problematica è supportata da HPLIP)

Sfortunatamente, le librerie HPLIP non registrano nell’unità CUPS del journal, quindi se la propria coda di stampa è installata con un driver HPLIP (il suo URI del dispositivo inizia con hp://), è necessario il log del journal legato all’incidente.

Come avviare la cattura della registrazione del journal legata all’incidente

In un nuovo terminale o scheda del terminale, eseguire:

journalctl -f > journal_whole_log

Come ottenere la registrazione del journal legata all’incidente

Dopo aver attivato la condizione di errore che si sta cercando di diagnosticare, ad esempio stampando qualcosa, eseguendo uno script HP ecc., si termina la cattura del log del journal legato all’incidente dal passaggio precedente con <ctrl>+<c>.

Disattivare la registrazione di debug

Si prega di allegare cups_job_log per il lavoro problematico, cups_whole_log o journal_log se si è catturato l’intero log di cupsd durante l’evento problematico, alla segnalazione di bug come allegato.

Quindi, per disattivare le informazioni di debug, eseguire:

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

Altri comandi per lavorare con systemd-journald

Visualizzare i messaggi di log con:

journalctl -u cups -e

oppure:

journalctl -u cups --since=...

Per filtrare i messaggi relativi a un ID di lavoro specifico, usare:

journalctl -u cups JID=...

(il completamento con il tasto tab mostrerà quali ID di lavoro hanno messaggi di log)

Registrazione di cups-browsed

Il demone cups-browsed è stato introdotto in Fedora intorno alla versione 1.5 di CUPS. Può cercare stampanti tramite trasmissioni Bonjour, trasmissioni CUPS (deprecate) e server LDAP, e creare o rimuovere code locali che puntano a tali stampanti. Può creare trasmissioni di code CUPS locali, ma questa funzione è contrassegnata come deprecata.

Per attivare la registrazione di debug è necessario aggiungere:

DebugLogging stderr

a /etc/cups/cups-browsed.conf.

I log saranno disponibili nel journal di sistema dopo il riavvio di cups-browsed.

Registrazione di debug degli script HPLIP

Gli script Python di HPLIP (ad es. hp-setup, hp-clean, hp-scan) hanno la registrazione di debug reindirizzata al descrittore di file di errore standard, quindi non vengono registrati nel journal. Per ottenere la loro registrazione di debug, eseguire lo script con il parametro -ldebug, ad esempio:

$ hp-setup -ldebug -i

e riprodurre il problema. Quindi, copiare i messaggi dal terminale in hp_script_log. Si prega di allegare anche questo file al ticket di Bugzilla.

Qual è la marca e il modello della mia stampante?

Ogni stampante ha un ID dispositivo specifico per il modello. È possibile scoprirlo con il comando lpinfo:

su -c "lpinfo -l -v"

Questo comando esegue ciascuno dei backend in modalità di rilevamento, per far loro segnalare i dispositivi che possono rilevare automaticamente. L’output sarà una serie di blocchi di righe, ognuno simile a questo:

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 =

La riga che identifica questo particolare tipo di modello è quella lunga che inizia con "device-id =" (qui mostrata su tre righe per motivi di spazio).

Si noti che se la stampante non può essere rilevata automaticamente, è comunque possibile scoprire l’ID del dispositivo eseguendo il backend appropriato con il nome host della stampante come argomento. I backend usb, parallel, snmp e dnssd tentano tutti di riportare l’ID del dispositivo effettivo fornito dalla stampante.

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

L’ID del dispositivo in questo caso è (vedere backend(7)) il penultimo campo.

Quali code di stampa sono disponibili?

Le code sulla propria macchina possono essere permanenti o temporanee. CUPS è in grado di elencare tutte le code di stampa disponibili sulla rete locale (code permanenti e temporanee) con:

$ lpstat -e

Per le code permanenti è possibile ottenere maggiori informazioni con:

$ lpstat -t

Quale driver sto usando?

Il file PPD per la coda della stampante può indicare quale driver è in uso. È possibile usare questo comando per scoprire quale driver viene utilizzato:

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

È anche possibile scoprirlo usando l’applicazione system-config-printer. Fare doppio clic sull’icona della coda e guardare il campo Marca e modello.

Per vedere i driver disponibili, fare clic sul pulsante Cambia… accanto a quel campo. Potrebbe essere utile provare un altro driver per vedere se presenta lo stesso problema.

Modelli senza driver

La maggior parte delle stampanti rilasciate dal 2010 sono in grado di supportare AirPrint o IPP Everywhere, il che significa che non hanno bisogno di essere installate per funzionare: il dispositivo viene trovato da Avahi e le capacità di stampa vengono comunicate tramite il protocollo IPP; sono praticamente dispositivi senza driver. Ci sono due soluzioni in Fedora che implementano IPP everywhere:

Modello 'everywhere' di CUPS
Driver 'driverless' di cups-filters

Modello 'everywhere' di CUPS

È l’implementazione CUPS dello standard IPP everywhere, disponibile come modello di stampante speciale. Il modello viene utilizzato quando si usa la coda temporanea di CUPS per il proprio dispositivo o se si installa il dispositivo come modello IPP Everywhere nell’interfaccia web di CUPS o tramite lpadmin (usando -m everywhere).

Poiché il file PPD creato dipende dalla comunicazione IPP con la stampante, abbiamo bisogno delle informazioni raccolte dal dispositivo. È possibile usare ipptool per questo:

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

Se necessario, allegare il file ipptool.attr creato al ticket di Bugzilla.

Driver 'driverless' di cups-filters

Driver speciale di cups-filters utilizzato per generare PPD secondo lo standard IPP Everywhere. Il driver viene utilizzato se si sceglie il modello driverless durante l’installazione della stampante.

Abbiamo bisogno anche dell’output della richiesta get-printer-attributes:

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

e i log di debug dal driver stesso quando genera il PPD per il dispositivo:

$ driverless -d cat <uri_dispositivo_ipp> 2> driverless_debug > ppd_creato

Se necessario, allegare tutti i file creati al ticket di Bugzilla.

Individuare l’origine del problema

Quando un lavoro di stampa viene elaborato, viene inviato attraverso una catena di filtri per convertire il file in un formato che la stampante può comprendere, e infine inviato a un backend, un programma che può trasportare i dati alla stampante. Modificando leggermente la modalità di stampa è possibile provare un percorso di stampa diverso per vedere se cambia qualcosa. Se questo risolve il problema, si sa in quale area si trovava il problema — includere tali informazioni in una segnalazione di bug in modo che possiamo risolverlo.

Applicazione

Provare a stampare da un’applicazione diversa per vedere se il problema scompare o se si verifica indipendentemente da come viene stampato un file. Provare a stampare il documento dalla riga di comando usando il comando lp.

Formato del documento

Se si hanno problemi a stampare file PDF, provare a stampare altri tipi di file per vedere se il problema riguarda la stampa in generale o se è specifico della stampa di file PDF. Provare a convertire il file in un formato diverso e a stamparlo.

Se il problema riguarda la stampa di file di testo, provare a rimuovere/installare il pacchetto paps. Questo pacchetto fornisce un filtro alternativo da testo a PostScript rispetto a quello fornito con CUPS.

Per ispezionare il documento inviato a CUPS per la stampa, abilitare l’opzione PreserveJobFiles in questo modo:

cupsctl PreserveJobFiles=yes

I documenti dei lavori inviati rimarranno in /var/spool/cups. Ci sono file con due tipi di nomi: dXXXXX-YYY e cXXXXX. dXXXXX-YYY è il file che va al sistema CUPS, il file non filtrato - XXXXX è l’ID del lavoro, riempito con zeri per avere una lunghezza di 5 caratteri, e YYY è il numero di sequenza del file nel lavoro. cXXXXX è il file che contiene le opzioni di stampa per un lavoro specificato dall’ID del lavoro in XXXXX. Si prega di allegare dXXXXX-YYY al bug per un lavoro quando si verifica il problema.

Esecuzione manuale dei filtri

Gli utenti più esperti possono provare a eseguire i filtri CUPS manualmente ed esaminare il file di dati a ogni passaggio mentre viene convertito tra diversi formati. Ecco un esempio di come farlo per una coda gutenprint chiamata pqueue con la pagina di prova di CUPS, che ha un suo tipo MIME speciale, application/vnd.cups-banner:

Prima è necessario conoscere la catena di filtri per application/vnd.cups-banner → printer/pqueue (tipo MIME di output). È possibile abilitare il debug, stampare una pagina di prova, ottenere il log del lavoro di CUPS e in cups_job_log si troverà qualcosa di simile a:

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)

oppure eseguire

/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

e si vedrà:

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

Questa catena di filtri è di cups-1.6. Con cups < 1.6 si potrebbe vedere bannertops → pstops → pstoraster.

Ora è possibile eseguire i filtri manualmente:

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

Qui, evince o okular possono essere usati per esaminare l’output dopo i primi due filtri, rasterview può essere usato per esaminare l’output del terzo filtro, e l’output dell’ultimo filtro deve essere ispezionato manualmente o inviato direttamente (lpr -oraw out.prn) alla stampante.

Driver

Se si ha accesso a una stampante di marca/modello diverso, potrebbe valere la pena provare a vedere se il problema si verifica su entrambe o solo su una. Questo può dare un’indicazione se si tratta di un problema con un driver particolare o se è un problema più generale.

Anche se si ha accesso a una sola stampante, spesso c’è una scelta di driver da usare per un dato modello, e provarli uno alla volta può essere utile per circoscrivere il problema. Vedere sopra per sapere come fare.

Foomatic

Per i driver Foomatic è possibile provare ad abilitare il debug di Foomatic modificando il file /etc/foomatic/filter.conf e aggiungendo una riga:

debug: 1

La prossima volta che si stampa un lavoro su una coda usando foomatic, il debug sarà inserito in /tmp/foomatic-rip.log, e il file di input ricevuto da foomatic-rip sarà in /tmp/foomatic-rip.ps.

Backend (trasporto del lavoro)

Potrebbe essere possibile provare un backend diverso. Usando system-config-printer, fare doppio clic sull’icona della coda della stampante e fare clic sul pulsante Cambia… accanto al campo URI del dispositivo. Si potrebbe vedere una freccia di espansione Connessione vicino all’angolo in basso a destra della finestra — fare clic su di essa per vedere quali backend sono disponibili. Per le stampanti HP connesse via USB, in genere possono essere utilizzati sia il backend hp che quello usb.

Per catturare la comunicazione USB:

trovare il numero del bus a cui è collegato il dispositivo USB, ad esempio:

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

      =

avviare la cattura dei pacchetti USB:

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

dove N è il numero del bus.

Per le stampanti di rete è possibile provare diversi protocolli.

socket è per HP JetDirect (solitamente porta 9100)
lpd è per le condivisioni di stampa UNIX di vecchio stile
smb è per le condivisioni CIFS da sistemi Windows
ipp è per i dispositivi abilitati al Protocollo di Stampa Internet e anche per altri server CUPS — È possibile catturare il traffico IPP con tcpdump in questo modo (il nome dell’interfaccia potrebbe essere diverso da p4p1):

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

bjnp è per il protocollo di rete proprietario bjnp di Canon (solitamente porta 8611)

Strumento di configurazione

Se il problema riguarda la configurazione delle code di stampa, provare a utilizzare uno degli altri metodi disponibili. Ce ne sono quattro:

L’applicazione Impostazioni di sistema di GNOME 3 (control-center), Impostazioni di sistema > Stampanti dalla shell di GNOME
system-config-printer, Sistema > Amministrazione > Stampa dal menu di GNOME
l’interfaccia web di CUPS, http://localhost:631/
gli strumenti a riga di comando lpadmin, lpoptions, cupsctl, cupsaccept, cupsenable ecc.

Casi d’uso

Ci sono diversi casi d’uso comuni quando si tratta di eseguire il debug dei problemi di stampa. Ne menzionerò alcuni con i passaggi per ottenere le informazioni necessarie.