Running Linux, 5th Edition - Matthias Kalle Dalheimer [288]
Enabling LPD support is necessary only to accept print jobs from LPD clients. If you want your CUPS daemon to print to a remote system that runs LPD, you can do so without activating this support. In this case, you need to specify the LPD server as a network print server, as described earlier in "Creating a printer definition."
The CUPS LPD support is provided by a small daemon called, appropriately enough, cups-lpd. This server is designed to be run via a super server, such as inetd or xinetd. On distributions that use xinetd, such as Fedora, Red Hat, and SUSE, look for a xinetd configuration file called cups-lpd in the /etc/xinetd.d directory. Look for a line in this file that reads disable = yes and edit it so that it reads disable = no. You can then restart xinetd or tell it to reload its configuration, and the cups-lpd server should be started. This server will accept print jobs using the LPD protocol just like BSD LPD or LPRng would, but it will redirect the job into the local CUPS queue of the same name.
If your system uses inetd, you must add an entry for cups-lpd to the /etc/inetd.conf file:
printer stream tcp nowait lp /usr/lib/cups/daemon/cups-lpd cups-lpd
Some systems will require changes to this configuration. For instance, you might want to call cups-lpd via TCP Wrappers (tcpd) rather than calling cups-lpd directly. As with xinetd, you must restart inetd or tell it to reload its configuration to start cups-lpd.
Printer Troubleshooting
With any luck, if you follow the instructions in this chapter, your printer will work with little or no fuss. Unfortunately, CUPS configuration doesn't always work as planned, and printer troubleshooting can be tricky and frustrating. Although we can't provide a sure-fire way to get your printer working, we can provide some suggestions that can help you track down the source of problems and find solutions to them.
If possible, verify that the printer works in another OS on the same computer. Even a FreeDOS (http://www.freedos.org) boot floppy can be handy for such verification, at least for parallel and RS-232 serial printers . If the printer works in another OS, that rules out a lot of pure hardware problems. If not, that suggests (but does not prove) that the problem is hardware-related.
Try checking all hardware connections, from the power cables to the cables to the computer. Loose or defective cables can cause endless hours of trouble. If your printer has a power switch, check that the printer is turned on. (We know that sounds incredibly basic, but failure to turn on a printer really is a leading cause of problems!) While you're at it, check that you've got paper in the printer's paper trays—all of them, if it has multiple trays.
Examine the printer's front or top panel for any error signals. Some printers have LCDs that can display short messages such as out of paper or paper jam. Others rely on blinking LEDs. Consult your printer's manual for help interpreting these displays.
If you have a parallel or RS-232 serial printer, try sending a print job to the printer using its raw device file, as described earlier in "Verifying printer compatibility." If this doesn't work but the printer checks out physically, it could mean you're missing a kernel driver for your device. Loading it with modprobe will perhaps do the trick. Another possible cause of such problems is that you're using the wrong device file, so you might want to try others. If the printer's LEDs blink when you try to print, chances are the file is getting through but is in a format that the printer can't understand, so basic hardware functions are probably (but not certainly) working.
If you have a USB printer, check that the kernel has identified the printer by using