Follow Techotopia on Twitter

On-line Guides
All Guides
eBook Store
iOS / Android
Linux for Beginners
Office Productivity
Linux Installation
Linux Security
Linux Utilities
Linux Virtualization
Linux Kernel
System/Network Admin
Scripting Languages
Development Tools
Web Development
GUI Toolkits/Desktop
Mail Systems
Eclipse Documentation

How To Guides
General System Admin
Linux Security
Linux Filesystems
Web Servers
Graphics & Desktop
PC Hardware
Problem Solutions
Privacy Policy




SUSE Linux Enterprise Desktop Deployment Guide
Previous Page Home Next Page

19.7 Troubleshooting

The following sections cover some of the most frequently encountered printer hardware and software problems and ways to solve or circumvent these problems.

19.7.1 Printers without Standard Printer Language Support

Printers that do not support any common printer language and can only be addressed with special control sequences are called GDI printers. These printers 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. The actual problem is not the programming interface, but the fact that GDI printers can only be addressed with the proprietary printer language of the respective printer model.

Some printers can be switched to operate either in GDI mode or one of the standard printer languages. Some manufacturers provide proprietary drivers for their GDI 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.

19.7.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.

19.7.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 19-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 19-1 /etc/modprobe.conf: Interrupt Mode for the First Parallel Port

alias parport_lowlevel parport_pc
options parport_pc io=0x378 irq=7

19.7.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 19-2, the problem is caused by the remote lpd.

Example 19-2 Error Message from the 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.

netcat -u -l -p 631 & PID=$! ; sleep 40 ; kill $PID

If a broadcasting CUPS network server exists, the output appears as shown in Example 19-3.

Example 19-3 Broadcast from the CUPS Network Server


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 via TCP socket. See Section 19.4.2, 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 nmap man page.

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.

19.7.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.

19.7.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 /usr/bin/enable.

19.7.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 print-server -o to determine the job number on the server, provided the server has not already completed the print job (that is, sent it to the printer). Using this job number, the print job on the server can be deleted:

cancel -h print-server queue-jobnnumber

19.7.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:

  1. 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.

  2. 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 print-server -o to check which queue is currently printing. Delete the print job with cancel queue-jobnumber or cancel -h print-server queue-jobnumber.

  3. 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).

  4. Reset the printer completely by switching it off for some time. Then insert the paper and turn on the printer.

19.7.9 Debugging the CUPS Print System

Use the following generic procedure to locate problems in the CUPS print system:

  1. Set LogLevel debug in /etc/cups/cupsd.conf.

  2. Stop cupsd.

  3. Remove /var/log/cups/error_log* to avoid having to search through very large log files.

  4. Start cupsd.

  5. Repeat the action that led to the problem.

  6. Check the messages in /var/log/cups/error_log* to identify the cause of the problem.

SUSE Linux Enterprise Desktop Deployment Guide
Previous Page Home Next Page

  Published under the terms of the Open Publication License Design by Interspire