Chapter 12. Processo di stampa / 12.6. Possibili difficoltà e la loro risoluzione | ||||
|---|---|---|---|---|
 | 12.5. Particolarità di | Chapter 13. Lavorare in tutta mobilità sotto Linux |  | |
Chapter 12. Processo di stampa / 12.6. Possibili difficoltà e la loro risoluzione | ||||
|---|---|---|---|---|
| 12.5. Particolarità di | Chapter 13. Lavorare in tutta mobilità sotto Linux | | |
Nelle seguenti sezioni descriveremo le difficoltà hardware e software che si possono verificano durante il processo di stampa ed il modo di risolverli.
Una stampante che può essere indirizzata solo attraverso delle particolari sequenze di controllo si chiamano stampanti GDI. Questo tipo di stampante funzione solo con la versione di sistema operativo per la quale il produttore acclude i driver. GDI è una interfaccia di programmazione grafica sviluppata dalla Microsoft. Il problema non è rappresentato dalla interfaccia ma piuttosto dal fatto che le cosiddette stampanti GDI possono essere indirizzate esclusivamente per via di un linguaggio di stampante proprietario.
Esistono delle stampanti che oltre al modo GDI comprendono anche un linguaggio standard, a tal fine basta solo impostarle di conseguenza o passare da un modo all'altro. Per alcune stampanti GDI vi sono dei driver proprietari forniti dalla casa produttrice. Lo svantaggio che presentano tali driver è che non si può garantire né che armonizzano bene con il sistema di stampa installato né con tutte le piattaforme hardware. Le stampanti che invece comprendono un linguaggio standard non dipendono né da una versione in particolare del sistema di stampa né da una determinata piattaforma hardware.
Di solito non vale la pena investire del tempo nel tentativo di adattare un driver Linux proprietario, conviene piuttosto acquistare direttamente una stampante supportata. Non vale la pena in primo luogo perché con una stampante che funziona senza creare delle difficoltà il problema dei driver viene risolto una volta per tutte. Non si dovrà più installare del software driver particolare ed eventualmente configurarlo in modo speciale e ci si risparmierà di dover cercare degli aggiornamenti del driver nel caso in cui il sistema di stampa è stato modificato nelle versioni successive.
Se nel pacchetto manufacturer-PPDs non si trova alcun file PPD adatto ad una stampante PostScript, dovrebbe essere comunque possibile utilizzare un file PPD reperibile sul CD dei driver del produttore o scaricare un file PPD adatto dal sito web della casa produttrice della stampante.
Se il file PPD si presenta sotto forma di archivio zip (estensione .zip) oppure sotto forma di archivio zip auto scompattante (.exe) potete utilizzare unzip per scompattarlo. Informatevi innanzitutto sui termini licenza del file PPD. Eseguite quindi un test con cupstestppd per vedere se il file PPD si attiene alla "Adobe PostScript Printer Description File Format Specification, Version 4.3". Se viene visualizzato "FAIL" vuol dire che vi sono degli errori gravi nel file PPD e fate conto che vi saranno delle grosse difficoltà. Cercate di risolvere i problemi rilevati da cupstestppd. Se necessario rivolgetevi direttamente al produttore per richiedere un file PPD che faccia al vostro caso.
La cosa migliore si ha quando la stampante è connessa direttamente alla prima interfaccia parallela, e nel BIOS sono settate le seguenti impostazioni per l'interfaccia parallela:
Indirizzo IO 378 (esadecimale)
L'interrupt è irrelevante
Modo Normal, SPP oppure Output-Only
DMA disabilitato
Se nonostante queste impostazioni del BIOS la stampante non risulta essere indirizzabile tramite la prima porta parallela, l'indirizzo IO - seguendo l'impostazione del BIOS - va inserito esplicitamente con 0x378 in /etc/modprobe.conf. Se vi sono due porte parallele impostate sugli indirizzi IO 378 e 278 (esadecimale), allora essi vanno inserite nel seguente modo 0x378,0x278.
Se l'interrupt 7 non è stato ancora assegnato, potete farlo servendovi del file Example 12.1, “ /etc/modprobe.conf: l'interrupt per la prima porta parallela ”. Prima di abilitare l'interrupt date una occhiata al file /proc/interrupts per vedere quali interrupt vengono già usati, comunque dovete considerare che vengono indicati solo gli interrupt che vengono utilizzati in quel momento, condizione che mutua in base all'hardware che viene attivamente utilizzato. Tenete presente che l'interrupt per la porta parallela non può venir già utilizzato da qualche parte del sistema. In caso di dubbio impostate il modo polling con irq=none.
Connettete la stampante direttamente ad un computer. Configurate la stampante ed eseguite un test per stampanti connesse in locale, se tutto va bene le difficoltà non possono che essere dovute alla rete.
La rete TCP/IP deve funzionare in modo ineccepibile come anche la risoluzione dei nomi.
Con il seguente comando potete testare se è possibile creare una connessione TCP all' lpd (porta 515) sul sistema host:
netcat -z <host> 515 && echo ok || echo failed
Se non è possibile creare una connessione all' lpd allora la causa può essere dovuta al fatto che l'lpd non è in esecuzione oppure vi sono dei vistosi problemi di rete.
Dando come utente il seguente comando si può ottenere una rassegna dello stato (eventualmente molto dettagliata) sulla coda di stampa queue sull'host (remoto), purché l'lpd dell'host remoto sia in esecuzione ed accetti delle richieste:
echo -e "\004<queue>" \ | netcat -w 2 -p 722 <host> 515
Se l'lpd non risponde allora o l'lpd non è in esecuzione oppure vi sono dei problemi di rete. Se l'lpd risponde, allora si potrà chiarire il perché non è possibile stampare sulla coda di stampa queue dell'host – Esempi:
Example 12.2. Messaggio di errore di lpd
lpd: your host does not have line printer access lpd: queue does not exist printer: spooling disabled printer: printing disabled
Nel caso di una risposta del genere la causa del problema è dovuta all' lpd remoto.
Con il seguente comando potete verificare se vi è un server di rete CUPS sulla rete, il quale dovrebbe indicare via broadcast ogni 30 secondi tramite la porta UDP 631 le sue code di stampa:
netcat -u -l -p 631 & PID=$! ; sleep 40 ; kill $PID
Dopo ca. 40 secondi dovrebbe venir visualizzato un output del genere se vi è un server di rete CUPS che invia dei broadcast:
Il seguente comando vi permette di verificare se è possibile creare una connessione TCP al cupsd (porta 631) sull' host:
In caso negativo il cupsd non è in esecuzione oppure vi è un grave problema di rete.
lpstat -h <host> -l -t
Questo comando ritorna una rassegna dello stato (eventualmente molto dettagliata) sulle coda di stampa sull'host, purché il cupsd dell'host remoto sia in esecuzione ed accetti delle richieste.
echo -en "\r" \ | lp -d <queue> -h <host>
Il comando riportato vi permette di verificare se la coda di stampa queue di host accetta un incarico di stampa composto da un solo carattere di ritorno di carrello (ingl. carriage return) — cioé viene eseguito solo un test senza stampare effettivamente alcunché — se non un foglio vuoto.
A volte si verificano dei problemi dovuti allo spooler di stampa in esecuzione in un printserver box non appena si registra un numero elevato di incarichi di stampa. Visto che il problema è dovuto allo spooler di stampa nel printserver box c'è poco da fare. Si può aggirare lo spooler di stampa indirizzando direttamente la stampante connessa al printserver box tramite socket TCP cfr. la sezione Section 12.4.2, “Stampante di rete”.
In questo modo il printserver box funge solo da convertitore tra le diverse possibilità per la trasmissione dei dati (rete TCP/IP e stampante collegata in locale). A tal fine deve essere nota la rispettiva porta TCP del printserver box. Con la stampante accesa e connessa al printserver box la porta TCP di solito, dopo aver acceso per un pò il printserver box, si lascia determinare tramite il programma nmap dal pacchetto nmap.
Ad esempio nmap indirizzo_IP nel caso di un printserver box emette:
Port State Service 23/tcp open telnet 80/tcp open http 515/tcp open printer 631/tcp open cups 9100/tcp open jetdirect
L'output indica che la stampante connessa al printserver box è indirizzabile tramite socket TCP sulla porta 9100. Di default nmap esegue una verifica solamente di un determinato elenco di porte generalmente note riportate in /usr/share/nmap/nmap-services. Per eseguire una verifica di tutte le porte possibili utilizzate il comando: nmap -p from_port-to_port IP-address (può durare un pò) — consultate a riguardo anche la pagina di manuale man nmap.
Con un comando del tipo
echo -en "\rHello\r\f" | netcat -w 1 <IP-address> <port> cat <file> | netcat -w 1 <IP-address> <port>
è possibile inviare una sequenza di caratteri oppure file ad una determinata porta per verificare se la stampante è indirizzabile tramite la porta in questione.
Per il sistema di stampa un incarico di stampa è stato portato a termine nel momento in cui il back-end CUPS ha concluso la trasmissione dei dati destinati alla stampante. Se in seguito durante l'ulteriore elaborazione dei dati si dovesse verificare un errore (ad esempio la stampante non riesce a stampare i dati che le sono stati trasmessi), il sistema di stampa non se ne accorge neanche. Se la stampante non riesce a stampare i dati, allora si dovrebbe selezionare un altro file PPD più congruo alla stampante.
Se il processo di trasmissione dei dati verso la stampante fallisce (di solito un back-end CUPS esegue diversi tentativi), il back-end CUPS, ad esempio usb o socket, segnala un errore al sistema di stampa, ovvero al cupsd. Il back-end decide quanti tentativi fare prima di dichiarare l'impossibilità della trasmissione dei dati. Visto che non ha senso continuare a tentare la coda di stampa interessata viene disabilitata da cupsd (disable). Dopo aver risolto il problema, l'amministratore di sistema la deve riabilitare tramite /usr/bin/enable.
Quando una rete di server CUPS segnala la propria coda di stampa ai client tramite browsing e sul client gira in locale un cupsd adatto, allora il cupsd del client accetta gli incarichi di stampa degli applicativi e li inoltra subito al cupsd del server. Quando il cupsd accetta un incarico di stampa, all'incarico viene assegnato un numero di incarico. Quindi il numero dell'incarico sul client è diverso da quello sul server. Dato che un incarico di stampa viene subito inoltrato, di solito non può venir cancellato ricorrendo al numero di incarico del client, dato che per il cupsd del client l'incarico di stampa si conclude con l'inoltro al del server (si veda sopra). Per cancellare l'incarico di stampa sul server va rilevato il numero dell'incarico tramite il seguente comando, se il server non ha ancora inviato l'incarico alla stampante:
lpstat -h <print-server> -o
Allora l'incarico di stampa può essere cancellato dal server con:
cancel -h <print-server> <coda_di_stampa>-<numero_di_incarico>
Gli incarichi di stampa permangono nelle code di stampa ed eventualmente vengono ristampati se durante il processo di stampa avete spento e riacceso la stampante o spento e riavviato il sistema. Un incarico di stampa recante degli errori va cancellato dalla coda d stampa con il comando cancel.
Se un incarico presenta degli errori oppure il processo di comunicazione tra il sistema e la stampante risulta essere disturbato, la stampante non saprà cosa fare con i dati inviatele. L'esito spesso è che vengono stampati innumerevoli fogli con dei caratteri privi di senso.
Togliete tutta la carta nel caso di stampanti a getto di inchiostro oppure estrarre il vassoio nel caso di stampanti laser per interrompere il processo di stampa. Stampanti di buona qualità hanno un pulsante per interrompere il processo di stampa
Visto che l'incarico di stampa viene eliminato dalla coda di stampa solo dopo che è stato inviato completamente alla stampante, spesso lo si ritroverà ancora nella coda di stampa. Con lpstat -o (o lpstat -h print-server -o) fatevi indicare da quale coda di stampa provengono attualmente gli incarichi di stampa, e con cancel coda_di_stampa-numero_incarico (o cancel -h print-server coda_di_stampa-numero_incarico ) potete cancellare l'incarico. In questi casi potete ricorrere anche ai programmi KDE kprinter o kjobviewer.
Eventualmente vengono trasmessi ancora alcuni dati alla stampante anche se l'incarico di stampa è stato cancellato dalla coda di stampa. Verificate se vi è ancora un processo del back-end CUPS in esecuzione relativo alla coda di stampa in questione ed in caso affermativo fermatelo. Ad esempio, tramite il comando fuser -k /dev/lp0 potete terminare tutti i processi che accedono alla stampante o più precisamente alla porta parallela.
Resettate completamente la stampante staccando per un pò la spina. In seguito rimettete la carta e riaccendete la stampante.
Per analizzare il problema nel sistema di stampa CUPS si consiglia di procedere nel seguente modo:
Impostate il LogLevel debug in /etc/cups/cupsd.conf.
Fermate il cupsd.
Spostate /var/log/cups/error_log* per non dover passare al setaccio file di log troppo voluminosi.
Avviate il cupsd.
Ripetete ciò che ha causato il problema.
Adesso vi sono tanti messaggi in /var/log/cups/error_log*, che vi potranno essere utili nel tentativo di individuare la causa del problema.
