| This section contains strategies and suggestions for approaching variousprinting problems. The first step is to narrow down the problem as precisely as possible. Which printers are affected? Are all users affected or just the one with the problem? Once you've determined where the problem is, you can set about dealing with it. If you've installed a printer but nothing prints on it, check the following items: Make sure you're using the right kind of cable. Check the printer's documentation for the manufacturer's recommendations. Make sure the connections are good and that you've specified the right port in the configuration file or commands. If you're using a serial line, make sure the line has been deactivated in /etc/ttytab, /etc/ttys, or /etc/inittab. Signal init to reread its configuration file. Kill the getty process watching that line, if necessary. Verify that its queue is set up correctly. Send a file to it and then make sure something appears in the spool directory (use the -c option on the printing command under System V and AIX). If it doesn't, the protection on the spooling directories or files may be wrong. In particular, root may own something it shouldn't. On System V systems, the spool directories located under /var/spool/lp/request are usually owned by the user lp and are protected 755 (write access only for the owner) or sometimes 770. The files in the spool directories are owned by group and user lp and are protected 440. Under BSD, the spool directories are traditionally owned by user daemon or lp and group lp and also protected 755 (or more stringently). Under AIX, pending requests are stored in /var/spool/lpd/qdir, owned by user root and group printq and protected 660, and spooled files are stored in /var/spool/qdaemon, owned by user bin and group printq, and protected 660. Removing and recreating the queue will sometimes fix things. This works when the queue configuration looks okay but is actually messed up by an invisible control character or another junk character somewhere. It also works when you remember something you forgot the first time when you recreate the queue. When all else fails, check the log files. Error messages can appear in several places: the general syslog error log, the syslog lpr facility error log, and the queue's own log file (when supported). Of course, if any of these are not defined, error messages sent there will be lost. If a printer suddenly stops working and its configuration hasn't changed, try the following: Is the daemon still running? If not, restart it. If it is, it may still be worth stopping and restarting it if no other jobs are printing: # kill -9 pid-of-lpd-process BSD # /usr/lib/lpd # lpshut System V # /etc/init.d/lp start # enq -G AIX Has someone spooled a huge job? A very large bitmap may take over half an hour to print on some slow PostScript printers. PostScript printers can also take a very long time to print any complex graphics. If the Processing light is flashing, things are probably still OK; when a job finally overwhelms the printer, the printer usually prints an error page rather than just getting hung. Of course, your patience and that of other waiting users may run out well before then. Aborting the current job may clear up the problem (the colloquial term for such a job is wedged). Power-cycling the device will clear most device hang-ups, although you will often lose the job that was printing at the time. For problems with remote printing, try the following: Determine whether the printer is working locally. You can test remote job connectivity by creating a queue to a file and seeing if it is spooled properly. In this way, you can determine if the problem is network communications generally or something specifically related to the device. For example, network delays can cause a queue or printer to time out. If the preceding test fails, try connecting to the remote server's port 515 with telnet. You should get a connection. You may then get an error message about an improper "from address." The latter is from the lpd process and is not significant. Network printers also generally support telnet for configuration purposes. Try connecting to the printer with telnet (no port number needed). You can then verify that the printer is accessible and also check its various settings for misconfiguration. Check the log file for further information. Note that you may need to check the various log file locations on both the remote and local host, because the relevant information can appear in any one of them depending on the particular problem. |
