LPI exam 102 prep, Topic 107: Printing

Manage printers and print queues

This section covers material for topic 1.107.2 for the Junior Level Administration (LPIC-1) exam 102. The topic has a weight of 1.

In this section, learn how to:

• Configure and monitor a print server
• Manage user print queues
• Troubleshoot general printing problems

Introduction

In the early days of computers, printing was done by line printers, which printed a line of text at a time using fixed-pitch characters and a single font. To speed up overall system performance, early mainframe computers interleaved work for slow peripherals such as card readers, card punches, and line printers with other work. Thus was born Simultaneous Peripheral Operation On Line or spooling, a term that is still commonly used when talking about computer printing.

In UNIX® and Linux systems, printing initially used the Berkeley Software Distribution (BSD) printing subsystem, consisting of a line printer daemon (lpd) running as a server, and client commands such as lpr to submit jobs for printing. This protocol was later standardized by the IETF as RFC 1179, "Line Printer Daemon Protocol".

System V UNIX also had a printing daemon. It was functionally similar to the Berkeley LPD, but had a different command set. You will frequently see two commands with different options that accomplish the same task. For example, lpr from the Berkeley implementation and lp from the System V implementation are both use to print files.

With advances in printer technology, it became possible to mix different fonts on a page and to print images as well as words. Variable pitch fonts, and more advanced printing techniques such as kerning and ligatures, all became possible. Several improvements to the basic lpd/lpr approach to printing were devised, such as LPRng, the next generation LPR, and CUPS, the Common UNIX Printing System.

Many printers capable of graphical printing use the Adobe PostScript language. A PostScript printer has an engine that interprets the commands in a print job and produces finished pages from these commands. PostScript is often used as an intermediate form between an original file, such as a text or image file, and a final form suitable for a particular printer that does not have PostScript capability. Conversion of a print job, such as an ASCII text file or a JPEG image to PostScript, and conversion from PostScript to the final raster form required for a non-PostScript printer is done using filters.

The rest of this tutorial focuses on the Common UNIX Printing System (CUPS), which supports the traditional commands as well as newer graphical interfaces to printing functions. CUPS 1.1 is assumed; it includes several features not in earlier versions, such as digest passwords for increased security. Many distributions and desktops provide front-end graphical programs for CUPS, so the material covered here is not exhaustive. This tutorial covers the major concepts, but a particular implementation may differ. Note also that physical installation of your printer is beyond the scope of this tutorial.

Back to top

Print servers

The CUPS server runs as a daemon process, cupsd under control of a configuration file normally located in /etc/cups/cupsd.conf. The /etc/cups directory also contains other configuration files related to CUPS. It is usually started during system initialization, but may be controlled by the cups script located in /etc/rc.d/init.d or /etc/init.d, according to your distribution. As with most such scripts, you can stop, start, or restart the daemon as shown in Listing 1.

                    
[root@attic4 ~]# /etc/rc.d/init.d/cups
Usage: cups {start|stop|restart|condrestart|reload|status}
[root@attic4 ~]# /etc/rc.d/init.d/cups stop
Stopping cups:                                             [  OK  ]
[root@attic4 ~]# /etc/rc.d/init.d/cups start
Starting cups:                                             [  OK  ]
[root@attic4 ~]# /etc/rc.d/init.d/cups restart
Stopping cups:                                             [  OK  ]
Starting cups:                                             [  OK  ]

The configuration file, /etc/cups/cupsd.conf, contains parameters that you may set to control such things as access to the printing system, whether remote printing is allowed, the location of spool files, and so on. On some systems, a second part describes individual print queues and is usually generated automatically by configuration tools. Listing 2 shows some entries for a default cupsd.conf file. Note that comments start with a # character, so entries that were changed from default would have the leading # character removed. Note also that the spool files are stored by default in the /var/spool filesystem as you would expect from the Filesystem Hierarchy Standard (FHS).

                    
#
# RequestRoot: the directory where request files are stored.
# By default "/var/spool/cups".
#

#RequestRoot /var/spool/cups

#
# RemoteRoot: the name of the user assigned to unauthenticated accesses
# from remote systems.  By default "remroot".
#

#RemoteRoot remroot

#
# ServerBin: the root directory for the scheduler executables.
# By default "/usr/lib64/cups".
#

#ServerBin /usr/lib64/cups

#
# ServerRoot: the root directory for the scheduler.
# By default "/etc/cups".
#

#ServerRoot /etc/cups

You should also be aware of the /etc/printcap file. This was the name of the configuration file for LPD print servers, and many applications still use it to determine available printers and their properties. It is usually generated automatically in a CUPS system, so you will probably not modify it yourself. However, you may need to check it if you are diagnosing user printing problems. An example is shown in Listing 3.

                    
# This file was automatically generated by cupsd(8) from the
# /etc/cups/printers.conf file.  All changes to this file
# will be lost.
xerox|Xerox Docuprint C20:rm=localhost.localdomain:rp=xerox:
anyprint|Pick any printer:rm=localhost.localdomain:rp=anyprint:
r220|Epson R220:rm=localhost.localdomain:rp=r220:

Each line here has a printer name and printer description as well as the name of the remote machine (rm) and remote printer (rp) on that machine. A traditional /etc/printcap file also describes the printer capabilities.

Finally,CUPS 1.1 introduced a passwd.md5 file. This allows CUPS users to be defined using the lppasswd command. The CUPS user ids do not have to be system userids.

Back to top

Print queues

A print queue is a logical entity to which users direct print jobs. Frequently, particularly in single-user systems, a print queue is synonymous with a printer. However, CUPS allows a system without an attached printer to queue print jobs for eventual printing on a remote system, and also, through the use of classes to allow a print job directed at a class to be printed on the first available printer of that class. These are discussed more in the final section of this tutorial.

Several commands permit inspection and manipulation of print queues. Some of these have their roots in LPD commands, although the currently supported options are frequently a limited subset of those supported by the original LPD printing system. Other commands are new for CUPS. In general, a user can manipulate his or her own print jobs, but root or another authorized user is usually required to manipulate the jobs of others. Most CUPS commands support a -E option for encrypted communication between the CUPS client command and CUPS server.

You can check the queues known to the system using the CUPS lpstat command. Some common options are shown in Table 3.

You may also use the LPD lpc command, found in /usr/sbin, with the status option. If you do not specify a printer name, all queues are listed. Listing 4 shows some examples of both commands.

                    
[ian@attic4 ~]$ lpstat -d
system default destination: xerox
[ian@attic4 ~]$ lpstat -v xerox
device for xerox: lpd://192.168.0.10/PS-66D975-P1
[ian@attic4 ~]$ lpstat -s
system default destination: xerox
members of class anyprint:
        r220
        xerox
device for anyprint: ///dev/null
device for r220: smb://MSHOME/DEN/EPSON220
device for xerox: lpd://192.168.0.10/PS-66D975-P1
[ian@attic4 ~]$ lpstat -a r220
r220 accepting requests since Sat 12 Aug 2006 04:01:38 PM EDT
[ian@attic4 ~]$ /usr/sbin/lpc status xerox
xerox:
        printer is on device 'lpd' speed -1
        queuing is disabled
        printing is enabled
        no entries
        daemon present

This example shows two printers, xerox and r220, and a class, anyprint, which allows print jobs to be directed to the first available of these two printers.

In the previous example, queuing of print jobs to xerox is currently disabled, although printing is enabled, as might be done in order to drain the queue before taking the printer offline for maintenance. Whether queuing is enabled or disabled is controlled by the accept and reject commands. Whether printing is enabled or disabled is controlled by the cupsenable and cupsdisable commands. In earlier versions of CUPS, these were called enable and disable, which allowed confusion with the bash shell builtin enable. Listing 5 shows how to enable queuing on printer xerox while disabling printing. Note that an authorized user must perform these tasks. This may be root or another authorized user. See the cupsd.conf file and the man pages for the lppasswd command for more information on authorizing users.

                    
[root@attic4 ~]# lpc status xerox
xerox:
        printer is on device 'lpd' speed -1
        queuing is enabled
        printing is enabled
        no entries
        daemon present
[root@attic4 ~]# cupsdisable xerox
[[root@attic4 ~]# lpstat -p -a
printer anyprint is idle.  enabled since Sat 12 Aug 2006 04:07:46 PM EDT
printer r220 is idle.  enabled since Sat 12 Aug 2006 04:01:38 PM EDT
printer xerox disabled since Sat 12 Aug 2006 06:43:09 PM EDT -
        Paused
anyprint accepting requests since Sat 12 Aug 2006 04:07:46 PM EDT
r220 accepting requests since Sat 12 Aug 2006 04:01:38 PM EDT
xerox accepting requests since Sat 12 Aug 2006 06:43:09 PM EDT

Managing print jobs on print queues

Now that you have seen a little of how to check on print queues and classes, let's look at how to manage print jobs on printer queues. The first thing you might want to do is find out whether any jobs are queued for a particular printer or for all printers. You do this with the lpq command. If no option is specified, lpq displays the queue for the default printer. Use the -P option with a printer name to specify a particular printer or the -a option to specify all printers, as shown in Listing 6.

                    
[ian@attic4 ~]$ lpq
xerox is not ready
Rank    Owner   Job     File(s)                         Total Size
1st     brendan 14      RobotPlayer.java                1024 bytes
2nd     ian     16      .bashrc                         1024 bytes
3rd     ian     17      .bashrc                         1024 bytes
[ian@attic4 ~]$ lpq
xerox is not ready
Rank    Owner   Job     File(s)                         Total Size
1st     brendan 14      RobotPlayer.java                1024 bytes
2nd     ian     16      .bashrc                         1024 bytes
3rd     ian     17      .bashrc                         1024 bytes
[ian@attic4 ~]$ lpq -P r220
r220 is ready
no entries
[ian@attic4 ~]$ lpq -a
Rank    Owner   Job     File(s)                         Total Size
1st     brendan 14      RobotPlayer.java                1024 bytes
2nd     ian     16      .bashrc                         1024 bytes
3rd     ian     17      .bashrc                         1024 bytes

In this example, three jobs, 14, 16, and 17, are queued for the printer named xerox. Note that when the -P option is included, the output indicates that the printer is not ready. Note also that user ian submitted a job twice, a common user action when a job does not print the first time. You can avoid printing the extra copy by removing a job from the queue with the lprm command. The usual authorization setup allows a user to remove his or her own jobs, but not those of other users. The root user or another authorized user can remove jobs for other users. With no options, the current job is removed. With the - option, all jobs are removed. Otherwise, you can give a list of jobs to be removed as shown in Listing 7.

                    
[[ian@attic4 ~]$ lprm
Password for ian on localhost?
lprm: Unauthorized
[ian@attic4 ~]$ lprm 17
[ian@attic4 ~]$ lpq
xerox is not ready
Rank    Owner   Job     File(s)                         Total Size
1st     brendan 14      RobotPlayer.java                1024 bytes
2nd     ian     16      .bashrc                         1024 bytes

Note that user ian was not able to remove the first job on the queue, because it was for user brendan. However, he was able to remove his own job number 17.

Another command that will help you manipulate jobs on print queues is the lp command. You may use it to alter attributes of jobs, such as priority or number of copies. Suppose user ian wants his job to print before that of user brendan, and he really did want two copies of it. The job priority ranges from a lowest priority of 1 to a highest priority of 100 with a default of 50. User ian could use the -i, -n, and -q options to specify a job to alter and a new number of copies and priority as shown in Listing 8. Note the use of the -l option of the lpq command, which provides more verbose output.

                    
[ian@attic4 ~]$ lp -i 16 -n 2
[ian@attic4 ~]$ lpq -l
xerox is not ready

ian: 1st                               [job 16 localhost]
        2 copies of .bashrc                     1024 bytes

brendan: 2nd                               [job 14 localhost]
        RobotPlayer.java                        1024 bytes

Finally, the lpmove command allows jobs to be moved from one queue to another. For example, we might want to do this because printer xerox is not currently printing. This command requires an authorized user. Listing 9 shows how to move these jobs to another queue, specifying first by printer and job id, then all jobs for a given printer. By the time we check the queues again, two of the jobs have already printed.

                    
[root@attic4 ~]# lpmove xerox-16 anyprint
[root@attic4 ~]# lpmove xerox r220
[root@attic4 ~]# lpq
xerox is not ready
no entries
[root@attic4 ~]# lpq -a
Rank    Owner   Job     File(s)                         Total Size
active  ian     18      fig1.gif                        26624 bytes

If you happen to use a print server that is not CUPS, such as LPD or LPRng, you will find that many of the queue administration functions that we have just looked at are handled as subcommands of the lpc command. For example, you might use lpc topq to move a job to the top of a queue. Other lpc commands may include disable, down, enable, hold, move, redirect, release, and start.

Back to top

Troubleshooting

If you are having trouble printing, try these tips:

• Ensure that the cups server is running. You can use the lpstat command, which will report an error if it is unable to connect to the cupsd daemon. Alternatively, you might use the ps -ef command and check for cupsd in the output.
  
  
• If you try to queue a job for printing and get an error message indicating that the printer is not accepting jobs results, use lpstat -a or lpc status to check that the printer is accepting jobs.
  
  
• If a queued job does not print, use lpstat -p or lpc status to check that the printer is accepting jobs. You may need to move the job to another printer as discussed in the next section.
  
  
• If the printer is remote, you may need to check that it still exists on the remote system and that it is operational.
  
  
• You may need to update the configuration file to allow a particular user or remote system to print on your printer.
  
  
• You may need to ensure that your firewall allows remote printing requests, either from another system to your system, or from your system to another, as appropriate.
  
  
• You may need to verify that you have the right driver (as discussed in the final section of this tutorial).

As you can see, printing involves the correct functioning of several components of your system and possibly network. In a tutorial of this length, we can only give you starting points for diagnosis. Most CUPS systems also have a graphical interface to the command-line functions that we discuss here. Generally, this interface is accessible from the local host using a browser pointed to port 631 (http://localhost:631 or http://127.0.0.1:631), as shown in Figure 1.

2 of 6 | Previous | Next

Comments

Back to top

Table of contents

• Before you start
• Manage printers and print queues
• Print files
• Printer installation and configuration
• Resources
• About the author

---

2 of 6 | Previous | Next

Dig deeper into Linux on developerWorks

IBM SmartCloud trial. No charge.

Unleash the power of hybrid cloud computing today!

---

Public and private solutions in one trial.

Special offers