|
|
|
|
9.8 Troubleshooting
The following sections cover some of the most frequently encountered
printer hardware and software problems and ways to solve or circumvent
these problems. Among the topics covered are GDI printers, PPD files, and
port configuration. Common network printer problems, defective printouts,
and queue handling are also addressed.
9.8.1 Printers without Standard Printer Language Support
These printers do not support any common printer language and can only
be addressed with special proprietary control sequences. Therefore they
can only work with the operating system versions for which the
manufacturer delivers a driver. GDI is a programming interface developed
by Microsoft* for graphics devices. Usually the manufacturer delivers
drivers only for Windows and because the Windows driver uses the GDI
interface, these printers are also called GDI
printers. The actual problem is not the programming
interface, but the fact that these printers can only be addressed with
the proprietary printer language of the respective printer model.
Some GDI printers can be switched to operate either in GDI mode or one
of the standard printer languages. See the manual of the printer whether
it is possible. Some models require a special Windows software to do the
switch (note that the Windows printer driver may always switch the
printer back into GDI mode when printing from Windows). For other GDI
printers there are extension modules for a standard printer language
available.
Some manufacturers provide proprietary drivers for their printers. The
disadvantage of proprietary printer drivers is that there is no
guarantee that these work with the installed print system and that they
are suitable for the various hardware platforms. In contrast, printers
that support a standard printer language do not depend on a special
print system version or a special hardware platform.
Instead of spending time trying to make a proprietary Linux driver work,
it may be more cost-effective to purchase a supported printer. This
would solve the driver problem once and for all, eliminating the need to
install and configure special driver software and obtain driver updates
that may be required due to new developments in the print system.
9.8.2 No Suitable PPD File Available for a PostScript Printer
If the manufacturer-PPDs package does not
contain any suitable PPD file for a PostScript printer, it should be
possible to use the PPD file from the driver CD of the printer
manufacturer or download a suitable PPD file from the Web page of the
printer manufacturer.
If the PPD file is provided as a zip archive (.zip) or a self-extracting
zip archive (.exe), unpack it with
unzip. First, review the license terms of the PPD
file. Then use the cupstestppd utility to check if
the PPD file complies with Adobe PostScript Printer Description
File Format Specification, version 4.3. If the utility returns
FAIL, the errors in the PPD files are serious and are
likely to cause major problems. The problem spots reported by
cupstestppd should be eliminated. If necessary, ask
the printer manufacturer for a suitable PPD file.
9.8.3 Parallel Ports
The safest approach is to connect the printer directly to the first
parallel port and to select the following parallel port settings in the
BIOS:
-
I/O address: 378 (hexadecimal)
-
Interrupt: irrelevant
-
Mode: Normal, SPP, or
Output Only
-
DMA: disabled
If the printer cannot be addressed on the parallel port despite these
settings, enter the I/O address explicitly in accordance with the
setting in the BIOS in the form 0x378 in
/etc/modprobe.conf. If there are two parallel ports
that are set to the I/O addresses 378 and
278 (hexadecimal), enter these in the form
0x378,0x278.
If interrupt 7 is free, it can be activated with the
entry shown in Example 9-1.
Before activating the interrupt mode, check the file
/proc/interrupts to see which interrupts are
already in use. Only the interrupts currently being used are displayed.
This may change depending on which hardware components are active. The
interrupt for the parallel port must not be used by any other device. If
you are not sure, use the polling mode with irq=none.
Example 9-1 /etc/modprobe.conf: Interrupt Mode for the First Parallel Port
alias parport_lowlevel parport_pc
options parport_pc io=0x378 irq=7
9.8.4 Network Printer Connections
- Identifying Network Problems
-
Connect the printer directly to the computer. For test purposes,
configure the printer as a local printer. If this works, the problems
are related to the network.
- Checking the TCP/IP Network
-
The TCP/IP network and name resolution must be functional.
- Checking a Remote lpd
-
Use the following command to test if a TCP connection can be
established to lpd (port 515)
on host:
netcat -z host 515 && echo ok || echo failed
If the connection to lpd cannot be established,
lpd may not be active or there may be basic
network problems.
As the user root, use the
following command to query a (possibly very long) status report for
queue on remote
host, provided the respective
lpd is active and the host accepts queries:
echo -e "\004queue" \
| netcat -w 2 -p 722 host 515
If lpd does not respond, it may not be active or
there may be basic network problems. If lpd
responds, the response should show why printing is not possible on
the queue on host. If you
receive a response like that in Example 9-2, the
problem is caused by the remote lpd.
Example 9-2 Error Message from lpd
lpd: your host does not have line printer access
lpd: queue does not exist
printer: spooling disabled
printer: printing disabled
- Checking a Remote cupsd
-
By default, the CUPS network server should broadcast its queues every
30 seconds on UDP port 631. Accordingly, the
following command can be used to test whether there is a CUPS network
server in the network. Make sure to stop your local CUPS daemon
before executing the command.
netcat -u -l -p 631 & PID=$! ; sleep 40 ; kill $PID
If a broadcasting CUPS network server exists, the output appears as
shown in Example 9-3.
Example 9-3 Broadcast from the CUPS Network Server
ipp://192.168.2.202:631/printers/queue
The following command can be used to test if a TCP connection can be
established to cupsd (port 631)
on host:
netcat -z host 631 && echo ok || echo failed
If the connection to cupsd cannot be established,
cupsd may not be active or there may be basic
network problems. lpstat -h host
-l -t returns a (possibly very long) status report for all
queues on host, provided the respective
cupsd is active and the host accepts queries.
The next command can be used to test if the
queue on host
accepts a print job consisting of a single carriage-return character.
Nothing should be printed. Possibly, a blank page may be ejected.
echo -en "\r" \
| lp -d queue -h host
-
Troubleshooting a Network Printer or Print Server Box
-
Spoolers running in a print server box sometimes cause problems when
they have to deal with a lot of print jobs. Because this is caused by
the spooler in the print server box, there is nothing you can do
about it. As a work-around, circumvent the spooler in the print
server box by addressing the printer connected to the print server
box directly with TCP socket. See Section 9.4, Network Printers.
In this way, the print server box is reduced to a converter between
the various forms of data transfer (TCP/IP network and local printer
connection). To use this method, you need to know the TCP port on the
print server box. If the printer is connected to the print server box
and powered on, this TCP port can usually be determined with the
nmap utility from the
nmap package some time after the print
server box is powered on. For example, nmap
IP-address may deliver the
following output for a print server box:
Port State Service
23/tcp open telnet
80/tcp open http
515/tcp open printer
631/tcp open cups
9100/tcp open jetdirect
This output indicates that the printer connected to the print server
box can be addressed via TCP socket on port 9100.
By default, nmap only checks a number of commonly
known ports listed in
/usr/share/nmap/nmap-services. To check all
possible ports, use the command nmap
-p from_port-to_port IP-address.
This may take some time. For further information, refer to the man
page of nmap.
Enter a command like
echo -en "\rHello\r\f" | netcat -w 1 IP-address port
cat file | netcat -w 1 IP-address port
to send character strings or files directly to the respective port to
test if the printer can be addressed on this port.
9.8.5 Defective Printouts without Error Message
For the print system, the print job is completed when the CUPS back-end
completes the data transfer to the recipient (printer). If the further
processing on the recipient fails, for example, if the printer is not
able to print the printer-specific data, the print system does not
notice this. If the printer is not able to print the printer-specific
data, select a different PPD file that is more suitable for the printer.
9.8.6 Disabled Queues
If the data transfer to the recipient fails entirely after several
attempts, the CUPS back-end, such as USB or
socket, reports an error to the print system (to
cupsd). The back-end decides whether and how many
attempts make sense until the data transfer is reported as impossible.
Because further attempts would be in vain, cupsd
disables printing for the respective queue. After eliminating the cause
of the problem, the system administrator must reenable printing with the
command cupsenable.
9.8.7 CUPS Browsing: Deleting Print Jobs
If a CUPS network server broadcasts its queues to the client hosts via
browsing and a suitable local cupsd is active on the
client hosts, the client cupsd accepts print jobs
from applications and forwards them to the cupsd on
the server. When cupsd accepts a print job, it is
assigned a new job number. Therefore, the job number on the client host
is different from the job number on the server. Because a print job is
usually forwarded immediately, it cannot be deleted with the job number
on the client host, because the client cupsd regards
the print job as completed as soon as it has been forwarded to the
server cupsd.
To delete the print job on the server, use a command such as
lpstat -h cups.example.com -o to determine the job number
on the server, provided the server has not already completed the print
job (that is, sent it completely to the printer). Using this job number,
the print job on the server can be deleted:
cancel -h cups.example.com queue-jobnnumber
9.8.8 Defective Print Jobs and Data Transfer Errors
Print jobs remain in the queues and printing resumes if you switch the
printer off and on or shut down and reboot the computer during the
printing process. Defective print jobs must be removed from the queue
with cancel.
If a print job is defective or an error occurs in the communication
between the host and the printer, the printer prints numerous sheets of
paper with unintelligible characters, because it is unable to process
the data correctly. To deal with this, follow these steps:
-
To stop printing, remove all paper from ink jet printers or open the
paper trays of laser printers. High-quality printers have a button for
canceling the current printout.
-
The print job may still be in the queue, because jobs are only removed
after they are sent completely to the printer. Use lpstat
-o or lpstat -h cups.example.com -o to check
which queue is currently printing. Delete the print job with
cancel
queue-jobnumber
or cancel -h cups.example.com
queue-jobnumber.
-
Some data may still be transferred to the printer even though the
print job has been deleted from the queue. Check if a CUPS back-end
process is still running for the respective queue and terminate it.
For example, for a printer connected to the parallel port, the command
fuser -k /dev/lp0 can be used to terminate all
processes that are still accessing the printer (more precisely: the
parallel port).
-
Reset the printer completely by switching it off for some time. Then
insert the paper and turn on the printer.
9.8.9 Debugging the CUPS Print System
Use the following generic procedure to locate problems in the CUPS print
system:
-
Set LogLevel debug in
/etc/cups/cupsd.conf.
-
Stop cupsd.
-
Remove /var/log/cups/error_log* to avoid having
to search through very large log files.
-
Start cupsd.
-
Repeat the action that led to the problem.
-
Check the messages in /var/log/cups/error_log* to
identify the cause of the problem.
|
|
|