| Printer Administration Potpourri for Large-Scale UNIX Systems
 
Bruce H. Hunter 
Small sites needn't worry much about printer administration.
With 
one or two printers and one spooler system, the complications
are 
few. For example, if the laser printer cartridge needs
changing, you 
simply tell everyone to hold their printer requests,
and then you 
open the printer and change the cartridge. However,
if you administer 
a system with 200 users using 20 printers, you'd wear
out your sneakers 
before you could tell all 200 people to hold their printer
requests. 
But you must stop new printer requests from being accepted
while you 
are working on the printer. If you don't, they might
fill the printer 
spooler, and then you'll really have trouble. 
Large UNIX computer sites also have an additional complication.
The 
larger the site, the more likely it is running more
than one version 
of UNIX. In fact, you could be dealing with as many
as three major 
versions of UNIX, each with its own, unique printer
spooler. BSD UNIX 
has lpr; AT&T System V UNIX and Xenix have a completely
different 
spooler called lp; and AIX has a printer spooling setup
that 
differs from both. 
Streetwise UNIX system administrators learn as much
as they can about 
all three printer spoolers. This article will give an
introductory 
overview of UNIX printer spoolers and will examine some
typical printer 
problems. 
BSD's lpr 
To power down a printer on a large site, you must do
more than shut 
off the printer. You must also kill the printer daemon
and disable 
the printer queue so that it can't accept more requests.
Listing 1 
shows how to stop a printer using the lpc command in
interactive 
mode. (Note the lpc> prompt.) The lpc stop command
disables 
the spooling daemon for that printer, and the disable
turns 
the queue off. 
The session in Listing 2 restarts the queue. Note that
the default 
machine is always lp. 
Troubleshooting 
Occasionally a printer daemon will get confused, making
it difficult 
to restart. For example, a user whose workstation or
UNIX PC doubles 
as a network print server might power down to move it. 
Look no further than lpc, which can be used interactively
or 
noninteractively. First use lpc to stop the daemon,
followed 
by lpc start to create a new lpr daemon. If the queue
is too full, use lpc clean to purge all cf, tf, 
and df files from the lpr spooler area. 
If the printer spooler system doesn't start, don't panic;
just do 
a shutdown and reboot. 
lpc and the Queue 
You can check queue health with the lpc status command.
Listing 3
shows a status report. By the way, don't panic at
that "no daemon 
present" message. This message refers to the server
daemon, which 
is spawned only when there is work to be done, and which
dies when 
the job is completed. An lpr daemon should always be
present 
and can be checked using ps. 
In addition to showing whether you have any lpr daemons
the 
ps command will also tell you if the daemons are alive.
The 
lpr daemon will nearly always be there as a child of
init 
(PPID 1), and it will have a very low PID number (160
in the example 
in Listing 4). If it is gone, you have a problem. 
Bypassing the Spooler 
If your printing problem is so severe that you can't
get anything 
going, try to send a few characters directly to the
printer's port: 
 
%su
password:
# echo "are you there?"> /dev/pp0 
 
If you're sending to a dot matrix printer, you'll hear
a brief zipping noise, and a form feed should reveal
your message. 
A laser printer, on the other hand, will give you a
whole page -- 
wait for it! The printer may be slow to recognize that
it won't be 
receiving more output for this page. Either way, this
simple test 
will tell you whether you have a printer or not.  
If you forget the printer's port name, use cat /etc/printcap
to find it. You should get a listing similar to that
in Listing 5. 
The line that assigns the printer to a port is: 
 
:lp=/dev/pp0 
 
If the search fails, check the port's permissions before
assuming the printer has taken off for Valhalla. You
are looking for 
generous write permissions like these: 
 
18% ls -l /dev/pp0
c-w--w--w- 1 root 56, 0 Nov 13
15:05 /dev/pp0
19% 
 
Even security fanatics wouldn't be concerned with these
permissions. After all, who is going to break into your
printer? Instead, 
guard root ownership by having a nonhuman user called
lp own 
it and all of its software.  
The AT&T System V Print Spooler 
AT&T changed its way of printing at System V Release
2 with its unique 
and complex lp spooler. Where Version 7 UNIX could spool
to 
only one printer, AT&T wrote System V to be a robust,
industrial-grade 
spooler so that UNIX could compete as a commercially
viable operating 
system with VMS AOS/VS and VM, both of which had fairly
impressive 
print spoolers. 
The lp spooling system is 10 years old now, but despite
its 
age, it remains particularly interesting because it
is capable of 
running multiple printers and printer batteries (with
printer batteries, 
each printer request is sent to the most available printer).
The limiting 
factor becomes the number of available ports. 
lp makes installing new printers easy and turning printers
on and off even easier. Since it gives you precise control,
you can 
start or stop any queue at any time. If a printer has
a paper jam, 
the spooler administrator can shut down the printer
(in software) 
and still allow the queue to continue to take requests.
If a printer's 
cartridge is wrecked and no space is available, the
lp spooler 
can stop that one spooler. If necessary -- and just
as easily -- 
an entire spooler can also be shut down. 
The heart of the lp system is its scheduler daemon,
lpsched, 
which handles all spooler activity either directly or
indirectly. 
Turn the scheduler on (using lpsched) and printing can
start; 
turn it off (using lpshut) and printing stops.  
Users feed printer requests to the scheduler with the
lp command, 
which takes single files or multiple files to any legitimate
printer: 
 
$ lp -dlw1 this.doc README doc.nroff.out 
 
or 
 
$ nroff -mm this.doc | lp -dlw3 
 
The cancel command cancels a print job. To use 
it, the user must know the printer name and the job
number asigned 
when lp was invoked: 
 
$ cancel 1w1-1234 
 
Before a submitted job has been handled by lpsched,
the accept and reject commands can be used to allow
the system or printer administrator to refuse requests. 
The lpsched daemon sends the print files to the printer
and 
the spool directory, /usr/spool/lp. (In new UNIX System
V it 
is /var/spool/lp.) The print requests leaving the spool
are 
channeled to predetermined printers (devices). These
printers can 
be turned on and off with the enable and disable commands,
and the requests can be moved from one printer to another
with the 
lpmove command. 
The administrator's own command for manipulating all
this is lpadmin. 
Similar in function to lpr's lpc command, lpadmin 
is a toolbox for the entire system. The lpstat command
monitors 
the lp system, providing the necessary lp stats. 
The lp manuals distinguish between devices and printers.
A 
printer is a virtual device, but a device is a physical
entity. Since 
all hardware is virtual in UNIX, this distinction is
not surprising. 
lp's major flaw is that it cannot do remote printing.
Still, 
it is a powerful spooling system, and its design is
well conceived. 
In spite of their multi-user capabiltiies, most PCs
on large sites 
are used by only one user at a time. (In fact, even
expensive workstations 
with sophisticated networking capabilities are often
used by only 
one person at a time, especially for memory intensive
applications.) 
However, because Xenix PCs are usually not equipped
to do remote printing, 
if there is a printer jam, the jam upsets the printer,
which in turn 
signals the UNIX PC that it is in trouble. Fortunately,
the lp 
daemon, lpsched, protects the system by killing itself.
Better to die in a noble cause than panic the kernel
and bring down 
the whole system. 
Printer Installations 
The lp spooler system provides for many different kinds
of 
printers by supplying a directory of different filters
for various 
printer models in the models directory. Administrators
copy the file 
to a directory, using the original as a model and modifying
it as 
necessary. To get an HP laserjet printer online, lpadmin
has 
to be told several things: 
 
printer name: lw1
printer model: hpjet
printer port: tty04 
 
Flags are used for each of these, and the result is
a 
command line that looks like this: 
 
# /usr/lib/lpadmin -plw1 -v/dev/tty04 -mhpjet 
 
Once the command is executed, the hpjet model file is
copied 
to the interface directory. The system now knows that
requests for 
lw1 will go to /dev/tty04. A printer created this way,
however, will not be enabled and will not accept requests,
so the 
enable and accept commands will have to be used separately.
Contrast this to the BSD lpr system, where lpc would
have taken care of both the accept and enable instructions. 
The AIX Spooler System for IBM RISC/6000s 
AIX is "POSIX compliant," so it looks like
UNIX to its users, 
but administrators soon see that the AIX printer spooler
system is 
only a "work-alike" printer spooler system
that barely resembles 
lp and lpr. AIX systems can spool to remote AIX and
BSD sites, but an AIX system cannot remove a job from
a BSD queue 
(a known bug). 
Actually, AIX has a complex and well-designed queueing
and spooling 
system in its own right. The queueing system can queue
anything that 
can be programmed, but in order to make the queueing
sytem print, 
you use a "front end" called enq. 
IBM made several front ends to keep users from complaining
about a 
strange printer system: 
 
1) qprt		AIX's print front end
2) lpr		lpr-like front end for Berkeley fans
3) lp		lp-like front end for System V types 
 
Each of these front ends queues the print request using
enq. The system also has alternative back ends. Although
enq 
is the main show, you also need to use the proper back
end to print. 
Any kind of queuing job can be done by switching the
back ends. The 
default back end for printing is piobe (an acronym for
printer 
I/O back end). 
The AIX printer spooler daemon for the queuing operation
is qdaemon, 
which is similar to BSD's lpd or System V's lpsched.
While we are dealing with similarities, lpr has printcap
and the IBM printer configuration file is qconfig. It
is similar 
in purpose to BSD's printcap, but it structures the
entries 
with stanzas. We will look at a few shortly. 
The Printer Front Ends 
When you work on AIX, you are constantly reminded that
IBM didn't 
worry about making AIX palatable to administrators.
Users see a familiar 
interface; lp and lpr are used as you would use them
on System V and Berkeley systems: 
 
lpr -P lw1 foo
lp -dlw1 foo 
 
Similarly, the AIX printing command qprt is almost 
intuitive if you know lpr: 
 
qprt -P lw1 foo 
 
The queuing command, enq, can be used for printing 
as well. Its syntax is close to qprt's: 
 
enq -P lw1 foo 
 
Printer Control 
Under AIX, users can cancel all their print jobs with
qcan 
 
qcan -P lw1 
 
or a single user job with the job number 
 
qcan -x 243 
 
However, as root the administrator can cancel 
all jobs 
 
qcan -X 
 
But before you cancel anything, check the status of
the 
queue with qck: 
 
qck -P lw1 
 
Then check the status of the spooler with qstatus 
 
qstatus -P lw1 
 
The session in Listing 6 shows where to find qstatus
and includes sample output. The key word READY tells
you that 
the print job is active and ready to print. 
/etc/qconfig 
AIX supplies a printcap-like function without printcap.
The configuration file for the AIX queuing system, qconfig,
is made up of structures called stanzas. Figure 1 contains
a few of 
the keys to these stanzas. Figure 2 shows a few lines
from a typical 
qconfig. 
qdaemon 
qdaemon, the queue daemon for AIX printing and queuing,
is 
always active. Listing 7 shows how to filter the qdaemon
entry 
from output. Like BSD's lpd and System V's lpsched,
qdaemon takes requests from enq and passes them to piobe. 
piobe 
The print job manager and back end is the spooler back-end
program 
called by qdaemon. qprt has dozens of options for print
control (such as font size) that it passes to piobe.
piobe 
is interesting because it runs in debug mode, using
different data 
types such as ASCII, pass through, and PostScript. It
can even invoke 
filters. 
Printer Security 
Because AT&T anticipated the move to C2 security,
its lp spooling 
system has always been set up as privileged commands
with root ownership 
removed from the lp system. A non-human user, lp, owns
the tools and files. This allows another level of privilege
(and responsibility) 
besides root or non-root users. 
Thus, when a problem like a printer jam is experienced,
the queue 
and the printer are shut off from the world with reject
and 
disable, set up as privileged commands. 
To get around the problem of a user having a jam and
not being able 
to do anything but helplessly watch the lp-spool daemon
die, 
you can give the lp password to trusted users and educate
them 
to do their own lp administration. 
Keep It Simple 
I hope this overview of printers and UNIX printer spoolers
helps you 
understand why it is wise to learn all three printer
spoolers as thoroughly 
as possible. 
But even when you have prepared for everything and think
you know 
most of the answers to whatever printer problem will
come up, things 
can still go wrong. For example, even though today's
laser printers 
are almost indestructible, at one time, my laser printer
started to 
rumble like a washing machine on spin dry with a couple
of bedspreads 
on the same side of the drum. As soon as I heard that
ominous rumbling 
sound, I powered off the laser printer, and using lpc,
stopped 
the printer queue and disabled the print server. 
I called for service, and after a while, a replacement
was delivered. 
Not even stopping to think, I took out the cartridge
from the faulty 
unit and put it in the replacement printer. To my embarrassment,
the 
new printer made the same noise, telling everyone about
the problem 
identification I should have done but didn't. The bottom
line: Keep 
it simple. I should have changed the cartridge first.
 
 
 About the Author
 
Bruce H. Hunter is the co-author, with Karen Hunter,
of UNIX 
Systems, Advanced Administration and Management Handbook
(Macmillan: 
1991). 
 
 
 |