What is LPD / LPR Printing?

Mon, 05/06/2024 - 12:31 By Dave Brooks
talking and listening


If you have set up a computer to print to a remote system, you may have heard of LPR and LPD. And, if you didn't hear those names, that's what you were using nonetheless.

When you set up using a remote hostname and queue name, you're working with LPR. LPR is the "line print requestor" or, in plain English, "please print this file at this location."

LPD is the "line print daemon" which is a way of saying it handles incoming print requests from LPR.

Nearly every computer system supports LPR/LPD and networked printers. Of course, it's not the only print protocol used today, but it is undoubtedly well-represented.

Line print?

I have shared space with a line printer exactly once in my professional career. This one used wide carriage paper with green bar stripes. I think it was rated for around 20 pages per second! And, was it ever loud.!Naturally, it was text only. The engineers on this project mainly used it to generate listings of their Fortran programs for the simulator project (officially).

We had a print command on our Data General computers which utilized this setup.

My first experience with the Berkely LPR/LPD system was on a later project, using a remarkably quiet PostScript printer. It was my first chance to acquaint myself with print server setup, which later led to some of the use cases I had in mind for RPM Remote Print Manager® ("RPM").

The days when Unix systems used line printers were a bit before my time, either that or the project had better funding than the university did at the time.


LPR/LPD comes from the Berkeley print system, part of the BSD or Berkeley Software Distribution. BSD, in turn, follows UNIX System V, one of the first commercial versions of Unix System V printing with similar commands and concepts to LPR. LPR/LPD was to be more uniform across different Unix systems.

Windows platforms, by default, support LPR/LPD printing. You may have to enable a setting to make LPR available to you.

The Internet Engineering Task Force (or IETF) sponsors documents that define network protocols and practices of many types. Among these documents are the RFCs, or "Request for Comments." RFC 1179, published in August 1990, defines LPR/LPD.

Common terms

This chart shows terms frequently used with LPR/LPD, matched with what I believe to be the correct perspective. I've included hyperlinks to take you to the explanation in this article.

Terminology Common aliases
LPR or "line print requestor"
  • LPR client
  • LPD client
LPD or "line printer daemon"
  • LPD service
  • LPD printer
Port 515 (referring to the TCP/IP port number)
  • LPR port
  • LPD port
The act of sending a job using LPR
  • LPR print and LPR printing
  • LPD printing

Introducing LPR

LPR is the "Line Printer Remote" protocol. It works with LPD, which is the "Line Printer Daemon." LPR and LPD work together like "send" and "receive" or "command" and "execute."

The "remote" part of LPR refers to sending a file to a printer or print server "somewhere," including the same office, building, or a different continent. The way LPR works over the network, printing locally works the same as printing anywhere on Earth (if your network connection is good).

LPR is very similar to uploading a file or sending a mail message, except that it's a print job. LPR includes three primary functions for sending print jobs:

  1. specify a named queue
  2. send data about the print job
  3. send the print job

Wikipedia adds the following advantages of LPR:

  • with LPR, you can migrate your print processes to a single print protocol
  • platform independence
  • and it's accessible via the Internet

Introducing LPD

LPD is the listener, and LPR sends requests to LPD. They speak the same language. That is the intent of the graphic at the top of the page.

The essential functions of LPD include:

  • waiting for LPR to send a job or other related command
  • handling multiple queues and multiple printers
  • matching a queue name with the proper job processing

Wikipedia points out that commercial applications of LPR and LPD offer more robust functionality and performance. We believe RPM, our LPD product, meets and exceeds this statement:

  • we handle as many concurrent incoming connections as Windows will support
  • unlimited named queues, each with a separate configuration
  • very wide variety of data processing options and outputs
  • extensive logging and error reporting

Network implications

  1. LPR/LPD is client/server
    1. LPR is the print client. When you configure LPR, you tell it the hostname or IP address of the host running LPD
    2. LPD is the print server, running on a computer that is accessible to LPR
  2. LPR/LPD uses port 515
    1. nearly any networking computer reserves port 515 for print requests, even if it does not have an LPD present
    2. sources refer to port 515 as the "LPR port" or the "LPD port" because LPR talks TO the port, and LPD listens ON the port
  3. Any print request includes:
    1. destination hostname or IP address, that is, where the LPD is running
    2. a TCP/IP port (nearly always 515)
    3. the name of the print queue you're sending the jobs to
    4. metadata which describes the job, including the job name, optionally the number of copies, and more
    5. and, naturally, the print data

LPD queues

I have reviewed the vendor specifications for numerous printers and hardware print servers. Nearly all of them supported LPD, with one or more pre-configured queues. Typically, one queue handles plain text while another supports pre-formatted print jobs in the printer's native language.

Many hardware print servers have no internal queue names, or they will have one such as "LPT1". They merely route all incoming jobs directly to the printer. If your print job is not in the correct format, you may lose the job with no reporting.

I believe that most, if not all, of the software print servers I've reviewed, allow you to add queue names and may specify one or more processing settings.

RPM lets you create essentially unlimited queues. I have seen one customer configuration with between 800 and 900 queues. The program startup took a little longer, but the job processing speed was not affected.

How RPM improves on error reporting

In the sources I reviewed for this article, one of the chief complaints about LPR/LPD is that you don't get much detail if there is an error.

On the other hand, RPM goes overboard regarding detail. We keep several internal logs that you can tune to the level of detail you want:

  • a diagnostic log for each module in the project, which you can turn on or off by module
  • a message log that covers the primary activities, such as receiving and printing, with varying degrees of detail
  • an event log for one-time or exception events
  • a critical events log that displays in the user interface for situations we deem worthy of immediate attention


  1. LPR/LPD is simple to set up
  2. LPR/LPD is very platform-independent; the LPR does not know what kind of host or printer the LPD is running on, and vice versa
  3. With a mature commercial product, you'll have many options not available in the lower-end


  1. "Line Printer Daemon protocol" https://en.wikipedia.org/wiki/Line_Printer_Daemon_protocol
  2. "List of printing protocols" https://en.wikipedia.org/wiki/List_of_printing_protocols
  3. "What is LPR?" https://web.mit.edu/network/appletalk/lpr.html
  4. "Difference between LPR and RAW" http://www.differencebetween.net/technology/protocols-formats/differenc…