Chapter 8 LP Print Service (Reference)

This chapter provides background information on the LP print service.

• The Structure of the LP Print Service

• LP Print Service Commands

• Functions of the LP Print Service

• How LP Administers Files and Schedules Local Print Requests

• Scheduling Network Print Requests

• Filtering Print Files

• What the Printer Interface Program Does

• How the lpsched Daemon Tracks the Status of Print Requests

• Cleaning Out Log Files

Where to Find Printer Tasks

The LP Print Service

The LP print service is a set of software utilities that allows users to print files while users continue to work. Originally, the print service was called the LP spooler. (LP stood for line printer, but its meaning now includes many other types of printers, such as laser printers. Spool is an acronym for system peripheral operation off-line.)

The print service consists of the LP print service software, any print filters you might provide, and the hardware, such as the printer, system, and network connections.

The Structure of the LP Print Service

This section describes the directory structure, files, logs, and commands of the LP print service.

LP Print Service Directories

The files of the LP print service are distributed among seven directories, as shown in the following table.

LP Print Service Configuration Files

The lpsched daemon stores configuration information in the /etc/lp directory, as described in the following table.

The configuration files listed in this table are private interfaces, and are subject to change in future releases. You should not build software that relies on these files being in their current locations or that relies on the data being in the format currently used.

These configuration files serve a similar function to the /etc/printcap file on lpd-based print servers.

You can check the contents of the configuration files, but you should not edit these files directly. Instead, use the lpadmin command to make configuration changes. Your changes will be written to the configuration files in the /etc/lp directory. The lpsched daemon administers and updates the configuration files.

The /etc/lp/printers directory has a subdirectory for each local printer known to the system. The following example shows the /etc/lp/printers subdirectories of printers sparc1 and luna.

$ ls -l /etc/lp/printers
drwxrwxr-x 2 lp lp 512 Jan 23 23:53 luna
drwxrwxr-x 2 lp lp 512 Jan 11 17:50 sparc1

The following table describes the files within each of the printer-specific directories.

The configuration file for the printer luna, /etc/lp/printers/luna/configuration, would typically appear as follows:

Banner: on: Always
Content types: PS
Device: /dev/term/b
Interface: /usr/lib/lp/model/standard
Printer type: PS
Modules: default

The terminfo Database

The /usr/share/lib directory contains the terminfo database directory, which contains definitions for many types of terminals and printers. The LP print service uses information in the terminfo database to initialize a printer, to establish a selected page size, character pitch, line pitch, and character set, as well as to communicate the sequence of codes to a printer.

Each printer is identified in the terminfo database with a short name. For a description of the structure of the terminfo database, see Printer Type. If necessary, you can add entries to the terminfo database, but doing so is a tedious and time-consuming process. For more information, see Adding a terminfo Entry for an Unsupported Printer.

Daemons and LP Internal Files

The /usr/lib/lp directory contains daemons and files used by the LP print service, as described in the following table.

LP Print Service Log Files

The LP print service maintains two sets of log files that are described in the following table.

Print Queue Logs

The scheduler for each system keeps a log of print requests in the /var/spool/lp/tmp/system and /var/spool/lp/requests/system directories. Each print request has two files, one in each directory, that contain information about the request. The information in the /var/spool/lp/requests/system directory can be accessed only by root or lp. The information in the /var/spool/lp/tmp/system directory can be accessed only by the user who submitted the request, root, or lp.

The following example shows the contents of the /var/spool/lp/tmp/starbug directory:

$ ls /var/spool/lp/tmp/starbug
5     5-0
# cat 5-0
C 1
D print1
F /etc/profile
P 20
T /etc/profile
t simple
U root
s 0000
v 2

These files remain in their directories only as long as the print request is in the queue. Once the request is finished, the information in the files is combined and appended to the /var/lp/logs/requests file. This file is described in the next section.

Use the information in the /var/spool/lp/logs directory if you need to track the status of a print request that is currently in the queue.

History Logs

The LP print service records a history of printing services in two log files, lpsched and requests. These log files are located in the /var/lp/logs directory. You can use the information in these logs to diagnose and troubleshoot printing problems. An example of the contents of the /var/lp/logs directory is as follows:

# cd /var/lp/logs
# ls
lpsched.1    requests    requests.2
lpsched      lpsched.2   requests.1
# 

The two most important log files for troubleshooting is the lpsched log, which contains information about local printing requests and the requests log, which contains information about print requests that are completed and no longer in the print queue.

The requests log has a simple structure, so that you can extract data using common UNIX shell commands. Requests are listed in the order they are printed, and are separated by lines showing their request IDs. Each line below the separator line, the line that starts with =, is marked with a single letter that identifies the kind of information contained in that line. Each letter is separated from the data by a single space.

The following example shows the contents of a requests log:

# pwd
/var/lp/logs
# tail requests.2
= print1-3, uid 0, gid 1, size 206662, Wed Mar 14 08:56:30 MST 2003
z print1
C 1
D print1
F /usr/dict/words
P 20
T /usr/dict/words
t simple
U root
s 0x0014
v 2
#

The following table shows the letter codes and the content of their corresponding lines in the LP requests log.

The following table shows the outcome codes in the LP requests log and their descriptions.

Spooling Directories

Files queued for printing are stored in the /var/spool/lp directory until they are printed, which might be only seconds. The following table shows the contents of the /var/spool/lp directory.

LP Print Service Commands

The following table lists frequently used LP print service commands. You must be root, lp, or assume an equivalent role to use the 1M commands.

Functions of the LP Print Service

The LP print service performs the following functions:

• Administers files and schedules local print requests

• Receives and schedules network requests

• Filters files, if necessary, so they print properly

• Starts programs that interface with the printers

• Tracks the status of jobs

• Tracks forms mounted on the printer

• Tracks print wheels currently mounted

• Delivers alerts to mount new forms or different print wheels

• Delivers alerts about printing problems

How LP Administers Files and Schedules Local Print Requests

The LP print service has a scheduler daemon called lpsched. The scheduler daemon updates the LP system files with information about printer setup and configuration.

The lpsched daemon schedules all local print requests on a print server, as shown in the following figure, whether users issue the requests from an application or from the command line. Also, the scheduler tracks the status of printers and filters on the print server. When a printer finishes a request, the scheduler schedules the next request, if one exists, in the queue on the print server.

Figure 8–1 The lpsched Daemon Schedules Local Print Requests

Each print server must have only one LP scheduler running. The scheduler is started when a system is booted, or enters run level 2, by the /etc/rc2.d/S80lp control script. Without rebooting the systems, you can stop the scheduler with the /etc/init.d/lp stop command and restart the scheduler with the /etc/init.d/lp start command. The scheduler for each system manages requests issued to the system by the lp commands.

Scheduling Network Print Requests

Each print client communicates directly with a print sever over the network. The communication is done between the requesting command, such as lp, lpstat, cancel, lpr, lpq, or lprm, and the print service on the print server. Doing so, reduces the print system overhead on client only systems, improving scalability, performance and accuracy of data.

Print servers listen for print request with the Internet services daemon (inetd). Upon hearing a request for print service from the network, the inetd daemon starts a program called the “protocol adaptor” (in.lpd). The protocol adaptor translates the print request and communicates it to the print spooler, and returns the results to the requester. This protocol adaptor starts on demand and exits when it has serviced the network request. This process eliminates idle system overhead for printing. This process also eliminates any additional system configuration for network printing support as was the case in previous versions of Solaris printing.

Filtering Print Files

Print filters are programs on the print server that convert the content of a queued file from one format to another format.

A print filter can be as simple or as complex as needed. The SunOS release provides print filters in the /usr/lib/lp/postscript directory that cover most situations where the destination printer requires the data to be in PostScript format. If you need filters for non-PostScript printers, you have to create the filters and add them to the systems that need filters.

A set of print filter descriptor files are provided in the /etc/lp/fd directory. These descriptor files describe the characteristics of the filter (for example, fast or slow filter), and point to the filter program (for example, /usr/lib/lp/postscript/postdaisy).

What the Printer Interface Program Does

The LP print service interacts with other parts of the operating system. The print service uses a standard printer interface program to do the following:

• Initialize the printer port, if necessary. The standard printer interface program uses the stty command to initialize the printer port.

• Initialize the printer. The standard printer interface program uses the terminfo database and the TERM shell variable to find the appropriate control sequences.

• Print a banner page, if necessary.

• Print the correct number of copies specified by the print request.

The LP print service uses the standard interface program, found in the /usr/lib/lp/model directory, unless you specify a different program. You can create custom interface programs, but you must make sure that the custom program does not terminate the connection to the printer or interfere with proper printer initialization.

How the lpsched Daemon Tracks the Status of Print Requests

The lpsched daemon keeps a log of each print request that it processes and notes any errors that occur during the printing process. This log is kept in the /var/lp/logs/lpsched file. Every night, the lp cron job renames the /var/lp/logs/lpsched file to a new lpsched.n file and starts a new log file. If errors occur or jobs disappear from the print queue, you can use the log files to determine what the lpsched daemon has done with a printing job.

Cleaning Out Log Files

The lpsched and requests log files in the /var/lp/logs directory grow as information is appended. The LP print service uses a default cron job to clean out the log files. The lp cron job is located in the /var/spool/cron/crontabs/lp file. The cron job periodically moves the contents of the log files. The contents of log are moved to log.1, and the contents of log.1 are moved to log.2. The contents of log.2 are lost (that is, replaced by the former contents of log.1) when log.2 gets overwritten.

How to Change Frequency of Printer Request Log Rotation

The requests log file on the printer server is rotated weekly rather than daily. You can change the rotation interval back to daily if the printer server is busy.

1. Become superuser or lp on the printer server.

2. Set the EDITOR environment variable.

   # EDITOR=vi # export EDITOR

3. Edit the lp crontab file.

   # crontab -e lp

4. Change the first line of the file which rotates the requests log files every Sunday (0) to an asterisk (*) for daily rotation:

   13 3 * * * cd /var/lp/logs; if [ -f requests ]; then if [ -f requests.1 ]; then /bin/mv requests.1 requests.2; fi; /usr/bin/cp requests requests.1; >requests; fi

5. Save the file and exit.

How Local Printing Works

The print request follows the same path it would if the client and server were separate systems. Requests always flow from client to server following the same path.

The following figure shows what happens when a user submits a request to print a PostScript file on a local printer, which is a printer connected to the user's system. The lpsched daemon on the local system does all processing, which might include matching the printer and content type, identifying the default printer, filtering the request, and starting the specified printer interface program.

The printer interface program does the following:

• Prints the banner page.

• Catches printer faults.

• Determines the printer fault policy to either reset, continue, or begin the print job over again.

• Finally, the interface program uses the lpcat program to download the print request to the local printer's serial port.

Figure 8–2 The Local Printing Process

How Remote Printing Works

The following figure shows what happens when a user on a Solaris print client submits a print request to an lpd-based print server. The command opens a connection and handles it's own communications with the print server directly.

Figure 8–3 Printing Between a Solaris Print Client and a lpd-based Print Server

The following figure shows a lpd-based print client submitting a print request to a Solaris print server. The lpd daemon handles the local part of the print request and the connection to the print server. On the print server, the inetd process waits for network printing requests and starts a protocol adaptor to service the request. The protocol adaptor communicates with the lpsched daemon, which processes the request on the print server.

Figure 8–4 Printing Between a lpd-based Print Client and a Solaris Print Server

The following figure shows what happens when a user on a Solaris print client submits a print request to a Solaris print server. The print command on the print client handles the local part of each print request by communicating directly with the print server.

The inetd process on the print server monitors network printing requests and starts a protocol adaptor to communicate with the lpsched daemon on the print server, which processes the print request.

Figure 8–5 Printing Between a Solaris Print Client and a Solaris Print Server