Problem with printing using lpd

[Andrew Kaplan]

Hi there --

One of our Fedora Core 2 workstations is unable to send lpd jobs to printers that are on a different subnet. Although CUPS is available, the primary application that is used on the workstation utilizes the lpd service. When a test page is attempted within the Setup/Printer Configuration utility, the error message that is displayed is the following:

There was an error trying to print the test page.

When I try to start the lpd daemon, via the /etc/init.d/lpd script, the following error appears on-screen:

Starting lpd: Warning - : Bad printcap entry - missing 'sd' or 'client' entry?
Fatal error - Cannot bind to lpd port '515'
[FAILED]

The CUPS utility is running on the system in question, and test pages from other applications, as well as within the CUPS itself are printed without any issues. I stopped CUPS, and tried the above steps again without any success.

Does anyone have any ideas as to what is causing this, and how it can be corrected? Thanks.

[Matti_Kurkela]

CUPS can provide LPD service too. Trying to run two separate print spooler systems in one machine is going to cause problems.

Your LPD error message would suggest that something else is already holding the LPD port. It might be xinetd, which is set up to start "cups-lpd" whenever something connects to the lpd port. Stopping CUPS won't change this in any way: you would have to disable the "cups-lpd" service to allow your lpd daemon to start up.

Use "lsof -i tcp:515" to see which process is holding the lpd port and thus preventing the lpd daemon from starting up.

In Debian at least, the CUPS support for lpd protocol is delivered as a separate package, named "cups-bsd".

As your CUPS printing system seems to work, I would recommend that you try to eliminate the extra lpd from your set-up and make sure CUPS has the lpd compatibility package installed.

MK

[skt_skt]

check "service lpd status"(old linux versions) and "service cups status". (new LINUX versions)


here is a sample entry in /etc/printcap

Pr_23_00:\
:ml=0:\
:mx=0:\
:sd=/var/spool/lpd/Pr_23_00:\
:af=/var/spool/lpd/Pr_23_00/Pr_23_00.acct:\
:sh:\
:lp=|/usr/share/printconf/util/jetdirectprint:

Also check if you have any default printer configured for your failing application. if the application is runnning on another node than the server where printer is confifured then check port .
"telnet printerip 515"

Some time the firwall make trouble too.

[Andrew Kaplan]

Hi there --

I ran the service commands for lp and cups, and the results were the following: lp was an unrecognized service, and cups was shown to be running. I had previously removed lp from the system in question, so the above output appears to make sense.

The lsof -i command came back with the following output:

COMMAND PID USER FD TYPE DEVICE SIZE NODE NAME
xinetd 3432 root 6u IPv4 5664 TCP *:printer (LISTEN)

The telnet localhost 515 and telnet 515 commands showed a connection was made on the port in question, but no other output was generated.

Does anyone have any other ideas? Thanks.