This chapter provides background information on the LP print service.
"How LP Administers Files and Schedules Local Print Requests"
"How the lpsched Daemon Tracks the Status of Print Requests"
For step-by-step instructions on print management tasks, see:
The LP print service is a set of software utilities that allows users to print files while they 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 (the printer, system, and network connections).
This section describes the directory structure, files, logs, and commands of the LP print service.
The files of the LP print service are distributed among seven directories, as shown in the table below.
Table 8-1 Directories for the LP Print Service
Directory |
Contents |
---|---|
/usr/bin |
The LP print service user commands |
/etc/lp |
A hierarchy of LP server configuration files |
/usr/share/lib |
The terminfo database directory |
/usr/sbin |
The LP print service administrative commands |
/usr/lib/lp |
The LP daemons; directories for binary files and PostScript filters; and the model directory (which contains the standard printer interface program) |
/var/lp/logs |
The logs for LP activities: lpsched.n - Messages from lpsched and requests.n - Information about completed print requests |
/var/spool/lp |
The spooling directory where files are queued for printing |
/var/spool/print |
The LP print service client-side request staging area |
The scheduler stores configuration information in LP configuration files located in the /etc/lp directory, as described in the table below.
The configuration files listed in the table below 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.
File |
Type |
Description |
---|---|---|
classes |
Directory |
Files identifying classes provided by the lpadmin -c command. |
fd |
Directory |
Description of existing filters. |
filter.table |
File |
Print filter lookup table. |
forms |
Directory |
Location to put files for each form. Initially, this directory is empty. |
interfaces |
Directory |
Printer interface program files. |
logs |
Link to /var/lp/logs |
Log files of printing activities. |
model |
Link to /usr/lib/lp/model |
The standard printer interface program. |
printers |
Directory |
Directories for each local printer. Each directory contains configuration information and alert files for an individual printer. |
pwheels |
Directory |
Print wheel or cartridge files. |
These configuration files serve a similar function to the /etc/printcap file in the SunOS 4.1 release.
You can check the contents of the configuration files, but you should not edit them directly. Instead, use the lpadmin(1M) 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.
File Name |
Description |
---|---|
alert.sh |
Shell to execute in response to alerts |
alert.vars |
Alert variables |
configuration |
Configuration file |
users.deny |
List of users to whom printer access is denied |
comment |
Printer description |
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 /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. See "Printer Type" for a description of the structure of the terminfo database. If necessary, you can add entries to the terminfo database, but it is a tedious and time-consuming process. See "Adding a terminfo Entry for an Unsupported Printer".
The /usr/lib/lp directory contains daemons and files used by the LP print service, as described in the table below.
Table 8-3 Contents of the /usr/lib/lp Directory
File |
Type |
Description |
---|---|---|
bin |
Directory |
Contains files for generating printing alerts, slow filters, and queue management programs. |
lpsched |
Daemon |
Manages scheduling of LP print requests. |
model |
Directory |
Contains the standard printer interface program. |
postscript |
Directory |
Contains all PostScript filter programs provided by the LP print service. These filters come with descriptor files in the /etc/lp/fd directory that tell the LP print service the characteristics of the filters and where to locate them. |
The LP print service maintains two sets of log files described in the following table.
Log File Name |
Description |
---|---|
Set lpr.debug in /etc/syslog.conf to enable LP print service logging |
|
/var/spool/lp |
A list of current requests that are in the print queue |
/var/lp/logs/requests |
An ongoing history of print requests |
The scheduler for each system keeps a log of print requests in the directories /var/spool/lp/tmp/system and /var/spool/lp/requests/system. 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 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/terra directory:
$ ls /var/spool/lp/tmp/terra 20-0 21-0 terra$ cat 21-0 C 1 D slw2 F /etc/default/login P 20 t simple U tamiro s 0x1000 |
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 file /var/lp/logs/requests, which is described in the next section.
Use the information in the /var/spool/lp logs if you need to track the status of a print request that is currently in the queue.
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. This is an example of the contents of the /var/lp/logs directory:
# cd /var/lp/logs # ls lpsched.1 requests requests.2 lpsched lpsched.2 requests.1 # |
The files with the .1 and .2 suffixes are copies of the previous day's logs. Each day, the lp cron job cleans out the lpsched and requests log files and keeps copies for two days. See "Creating and Editing crontab Files" for suggestions on modifying the cron job for cleaning out the requests log.
The two most important log files for troubleshooting is the lpsched log, which contains information about local printing requests
The requests log contains information about print requests that are completed and no longer in the print queue. Once a request is finished printing, the information in the /var/spool/lp log files is combined and appended to the /var/lp/logs/requests log.
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 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 = slw2-20, uid 200, gid 200, size 5123, Tue Jun 17 10:16:10 MDT 1998 z slw2 C 1 D slw2 F /etc/motd P 20 t simple U irving s 0x0100 # |
The table below shows the letter codes and the content of their corresponding lines in the LP requests log.
Table 8-4 Letter Codes in the LP requests Log
Letter |
Content of Line |
---|---|
= |
The separator line. It contains the following items: request ID, user ID (UID), and group IDs (GIDs) of the user, the total number of bytes in the original (unfiltered) file size, and the time when the request was queued. |
C |
The number of copies printed. |
D |
The printer or class destination or the word any. |
F |
The name of the file printed. The line is repeated for each file printed; files were printed in the order shown. |
f |
The name of the form used. |
H |
One of three types of special handling: resume, hold, and immediate. |
N |
The type of alert used when the print request was successfully completed. The type is the letter M if the user was notified by email or W if the user was notified by a message to the terminal. |
O |
The printer-dependent -o options (for example, nobanner). |
P |
The priority of the print request. |
p |
The list of pages printed. |
r |
A single-letter line that is included if the user asked for "raw" processing of the files (the lp -r command). |
S |
The character set, print wheel, or cartridge used. |
s |
The outcome of the request, shown as a combination of individual bits expressed in hexadecimal form. Several bits are used internally by the print service. The bits and what they mean are describe in the table below. |
T |
The title placed on the banner page. |
t |
The type of content found in the files. |
U |
The name of the user who submitted the print request. |
x |
The slow filter used for the print request. |
Y |
The list of special modes for the print filters used to print the request. |
z |
The printer used for the request. This printer differs from the destination (the D line) if the request was queued for any printer or a class of printers, or if the request was moved to another destination. |
The table below shows the outcome codes in the LP requests log and their descriptions.
Table 8-5 Outcome Codes in the LP requests Log
Outcome Code |
Description |
---|---|
0x0001 |
The request was held pending resume. |
0x0002 |
Slow filtering is running. |
0x0004 |
Slow filtering finished successfully. |
0x0008 |
The request is on the printer. |
0x0010 |
Printing finished successfully. |
0x0020 |
The request was held pending user change. |
0x0040 |
The request was canceled. |
0x0080 |
The request will print next. |
0x0100 |
The request failed filtering or printing. |
0x0200 |
The request is in transit to a remote printer. (obsolete) |
0x0400 |
The user will be notified. |
0x0800 |
A notification is running. |
0x1000 |
A remote system has accepted the request. (obsolete) |
0x2000 |
The administrator placed a hold on the request. |
0x4000 |
The printer had to change filters. |
0x8000 |
The request is temporarily stopped. |
Files queued for printing are stored in the /var/spool/lp directory until they are printed, which might be only seconds. The table below shows the contents of the /var/spool/lp directory.
Table 8-6 Contents of the /var/spool/lp Directory
File |
Type |
Description |
---|---|---|
SCHEDLOCK |
File |
Lock file for the scheduler. Check for this file if the scheduler dies and will not restart. |
admins |
Directory |
Link to /etc/lp. |
bin |
Directory |
Link to /usr/lib/lp/bin. |
logs |
Link |
Link to ../lp/logs where completed print requests are logged. |
model |
Link |
Link to /usr/lib/lp/model. |
requests |
Directory |
Directory that contains subdirectories for each configured printer where print requests are logged until printed. Users cannot access this log. |
system |
Directory |
A print status file for the system. |
temp |
Link |
Link to /var/spool/lp/tmp/hostname, which contains the spooled requests. |
tmp |
Directory |
Directory for each configured printer where print requests are logged until printed. Changes to existing print requests are also recorded in this log. |
The table below lists frequently used LP print service commands. You must be root or lp to use the 1M commands.
Table 8-7 Quick Reference to LP Print Service Commands
Command |
Task |
---|---|
Activate a printer |
|
Cancel a print request |
|
Send one or more file(s) to a printer |
|
Report the status of the LP print service |
|
Deactivate one or more printers |
|
Permit print requests to be queued for a specific destination |
|
Prevent print requests from being queued for a specific destination |
|
Set up or change printer configuration |
|
Set up or change filter definitions |
|
Set up or change preprinted forms |
|
Mount a form |
|
Move output requests from one destination to another |
|
Start the LP print service scheduler |
|
Stop the LP print service scheduler |
|
Set or change the default priority and priority limits that can be requested by users 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
The table below describes the directory structure and commands.
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 figure below, 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 there is one, in the queue on the print server.
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 control script /etc/rc2.d/S80lp. Without rebooting the systems, you can stop the scheduler with the /usr/lib/lp/lpshut command and restart the scheduler with the lpsched command. The scheduler for each system manages requests issued to the system by the lp commands.
Each print client communicates directly with a print sever over the network. The communication is done between the requesting command (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 now listen for print request with the Internet services daemon (inetd). Upon hearing a request for print service from the network, inetd starts a program called the "protocol adaptor" (in.lpd). The protocol adaptor translates the print request and communicates it to the print spooler, returning the results to the requester. It starts on demand and exits when it has serviced the network request. This eliminates idle system overhead for printing. It also eliminates any additional system configuration for networked printing support as was the case in previous versions of Solaris printing.
Print filters are programs on the print server that convert the content of a queued file from one format to another.
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 them.
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).
The LP print service interacts with other parts of the operating system. It uses a standard printer interface program to:
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 one. 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.
The lpsched daemon on both the print server and print client 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 /var/lp/logs/lpsched 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 lpsched has done with a printing job.
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. It 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.
# pwd /var/lp/logs # tail requests s 0x1010 = slw2-20, uid 200, gid 200, size 5123, Mon Jun 16 12:27:33 MDT 1997 z slw2 C 1 D slw2 F /etc/motd P 20 t simple U irving s 0x1010 # |
Starting with the Solaris 2.6 release, 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.
Become superuser or lp on the printer server.
Set the EDITOR environment variable.
# EDITOR=vi # export EDITOR |
Edit the lp crontab file.
# crontab -e lp |
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 |
Save the file and exit.
The figure below 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 local system does all processing; however, 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 figure below shows what happens when a user on a SunOS 5.8 print client submits a print request to a SunOS 4.1 print server. The command opens a connection and handles it's own communications with the print server directly.
The figure below shows a SunOS 4.1 print client submitting a print request to a SunOS 5.8 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 network listen process, inetd, 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.
The figure below shows what happens when a user on a SunOS 5.8 print client submits a print request to a SunOS 5.8 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.