Sometimes after setting up a printer, you find that nothing prints. Or, you might get a little farther in the process: something prints, but it is not what you expect, the output is incorrect or illegible.
Then, when you get past these problems, other problems might occur, such as:
lp commands hanging
Printers becoming idle
Users getting conflicting messages
Although many of the suggestions in this chapter are relevant to parallel printers, they are geared toward the more common serial printers.
When nothing prints, there are three general areas to check:
The printer hardware
The LP print service
If you get a banner page, but nothing else, this is a special case of incorrect output. See Troubleshooting Incorrect Output.
The hardware is the first area to check. As obvious as it sounds, you should make sure that the printer is plugged in and turned on. In addition, you should refer to the manufacturer's documentation for information about hardware settings. Some computers use hardware switches that change the characteristics of a printer port.
The printer hardware includes the printer, the cable that connects it to the computer, and the ports into which the cable plugs at each end. As a general approach, you should work your way from the printer to the computer. Check the printer. Check where the cable connects to the printer. Check the cable. Check where the cable connects to the computer.
Problems are more common with remote print requests that are going from a print client to a print server. You should make sure that network access between the print server and print clients is enabled.
If the network is running the Network Information Service Plus (NIS+), see System Administration Guide: Naming and Directory Services (NIS+) for instructions to enable access between systems. If the network is not running NIS or NIS+, before you set up print servers and print clients, include the Internet address and system name for each client system in the /etc/hosts file on the print server. Also, the IP address and system name for the print server must be included in the /etc/hosts file of each print client system.
# svcadm enable application/print/server
In addition to the scheduler running, a printer must be enabled and accepting requests before it will produce any output. If the LP print service is not accepting requests for a printer, the submitted print requests are rejected. Usually, in that instance, the user receives a warning message after submitting a print request. If the LP print service is not enabled for a printer, print requests remain queued on the system until the printer is enabled.
In general, you should analyze a printing problem as follows:
Follow the path of the print request step-by-step.
Examine the status of the LP print service at each step.
Is the configuration correct?
Is the printer accepting requests?
Is the printer enabled to process requests?
If the request is hanging on transmission, set up lpr.debug in syslog.conf to display the flow. See Debugging Printing Problems.
If the request is hanging locally, have notification of the printer device errors (faults) mailed to you, and re-enable the printer.
The procedures found in Troubleshooting Miscellaneous Printing Problems use this strategy to help you troubleshoot various problems with the LP print service.
Enabling lpr.debug in the /etc/syslog.conf file provides a variety of useful information. Because a large volume of information is provided, the preferred method is to enable this feature only while debugging printing problems.
For more information, see How to Debug Printing Problems.
If the printer and the print service software are not configured correctly, the printer might print, but it might provide output that is not what you expect.
If you used the wrong printer type when you set up the printer with the LP print service, inappropriate printer control characters can be sent to the printer. The results are unpredictable: nothing might print, the output might be illegible, or the output might be printed in the wrong character set or font.
If you specified an incorrect file content type, the banner page might print, but that is all. The file content types specified for a printer indicate the types of files the printer can print directly, without filtering. When a user sends a file to the printer, the file is sent directly to the printer without any attempt to filter it. The problem occurs if the printer cannot handle the file content type.
When setting up print clients, you increase the chance for a mistake because the file content types must be correct on both the print server and the print client. If you set up the print client as recommended with any as the file content type, files are sent directly to the print server and the print server determines the need for filtering. Therefore, the file content types have to be specified correctly only on the server.
You can specify a file content on the print client to off-load filtering from the server to the client, but the content type must be supported on the print server.
Many formatting problems can result when the default stty (standard terminal) settings do not match the settings required by the printer. The following sections describe what happens when some of the settings are incorrect.
When the baud setting of the computer does not match the baud setting of the printer, usually you get some output, but it does not look like the file you submitted for printing. Random characters are displayed, with an unusual mixture of special characters and undesirable spacing. The default for the LP print service is 9600 baud.
If a printer is connected by a parallel port, the baud setting is irrelevant.
Some printers use a parity bit to ensure that data received for printing has not been garbled during transmission. The parity bit setting for the computer and the printer must match. If they do not match, some characters either will not be printed at all, or will be replaced by other characters. In this case, the output looks approximately correct. The word spacing is all right and many letters are in their correct place. The LP print service does not set the parity bit by default.
If the file contains tabs, but the printer expects no tabs, the printed output might contain the complete contents of the file, but the text might be jammed against the right margin. Also, if the tab settings for the printer are incorrect, the text might not have a left margin, it might run together, it might be concentrated to a portion of the page, or it might be incorrectly double-spaced. The default is for tabs to be set every eight spaces.
If the output is double-spaced, but it should be single-spaced, either the tab settings for the printer are incorrect or the printer is adding a line feed after each return. The LP print service adds a return before each line feed, so the combination causes two line feeds.
If the print zigzags down the page, the stty option onlcr that sends a return before every line feed is not set. The stty=onlcr option is set by default, but you might have cleared it while trying to solve other printing problems.
If you type any of the lp commands (such as lpsystem, lpadmin, or lpstat) and nothing happens (no error message, status information, or prompt is displayed), chances are something is wrong with the LP scheduler. Such a problem can usually be resolved by stopping and restarting the LP scheduler. See How to Stop the Print Scheduler for instructions.
You might find a printer that is idle, even though it has print requests queued to it.
A printer might seem idle when it should not be for one of the following reasons:
The current print request is being filtered.
The printer has a fault.
Networking problems might be interrupting the printing process.
Slow print filters run in the background to avoid tying up the printer. A print request that requires filtering will not print until it has been filtered.
When the LP print service detects a fault, printing resumes automatically, but not immediately. The LP print service waits about five minutes before trying again, and continues trying until a request is printed successfully. You can force a retry immediately by enabling the printer.
When printing files over a network, you might encounter the following types of problems:
Requests sent to print servers might back up in the client system (local) queue.
Requests sent to print servers might back up in the print server (remote) queue.
Print requests submitted to a print server might back up in the client system queue for the following reasons:
The print server is down.
The printer is disabled on the print server.
The network between the print client and print server is down.
Underlying network software was not set up properly.
While you are tracking the source of the problem, you should stop new requests from being added to the queue. See How to Accept or Reject Print Requests for a Printer for more information.
If print requests back up in the print server queue, the printer has probably been disabled. When a printer is accepting requests, but not processing them, the requests are queued to print. Unless there is a further problem, once the printer is enabled, the print requests in the queue should print.
A user might enter a print request and be notified that the client system has accepted it, then receive mail from the print server that the print request has been rejected.
These conflicting messages might occur for the following reasons:
The print client might be accepting requests, while the print server is rejecting requests.
The definition of the printer on the print client might not match the definition of that printer on the print server. More specifically, the definitions of the print job components, like filters, character sets, print wheels, or forms are not the same on the client and server systems.
You should check that identical definitions of these job components are registered on both the print clients and print servers so that local users can access printers on the print servers.