Printing: BSD or System V?
Everyone wants to print. Predictions of the paperless
generating paper seems to be the primary use of computers.
On today's UNIX systems you may well have a choice between
System V spooling system (lp and lpsched) and the
BSD spooling system (lpr and lpd). System V derivatives
such as Sun Solaris 2 and Hewlett-Packard HP-UX come
with the System
V spooler. Apple A/UX comes with both spoolers. Linux
and OSF/1 have
the BSD spooler. Most flavors of UNIX offer both the
BSD and System
V user commands, regardless of the underlying spooler.
If your system comes with only the System V spooler,
you still have
the option of installing the BSD spooler. Source code
for the BSD
spooler is readily available -- for example, in the
source distribution. If you converted from SunOS 4.1
to Solaris 2,
the binaries from the former run just fine under the
latter (see the
sidebar, "Using the SunOS 4.1.2 Spooler under Solaris
The Spooler System
A spooler consists of three main parts: the commands
used by normal
users and by system administrators during normal spooler
the commands and procedures used by system administrators
the spooler and configure printers; and the spooler
spool queues, configuration files).
The User Interface
The user needs to spool the job, check on its status,
cancel the job. System administrators need to be able
to start and
stop the spooling system, cancel jobs, and perhaps reroute
spooled jobs to a different printer. Table 1 shows the
these tasks in the two systems. As the table shows,
both systems have
much the same capability. Shell scripts are often written
the options so that both sets of commands are available,
programs have lp or lpr hardwired into them.
The lp and lpr commands both have many anachronistic
options for doing things like setting margins or selecting
wheel and forms to be used. Today such functions are
in the PostScript files sent to the printer. For that
is often done by clicking an icon in total ignorance
of the underlying
At the system administration level, the System V spooler
commands, more separate configuration files, and is
basically a more
complex system. The BSD spooler, on the other hand,
depends on the
arcane syntax and semantics of the /etc/printcap file.
require the system administrator to take some action
to complete the
basic OS installation.
The System V spooler can be configured (under Solaris)
a GUI front end, or by using a collection of commands
a number of files. The latter approach is complicated
and messy, but
if you really have to maintain and understand the spooler,
you to do this at least once so you can see what is
going on under
the covers. An appendix in the appropriate manual leads
most of this process.
Installing the BSD spooler consists of editing the ASCII
to identify the printers, their capabilities, log and
and filters used to convert print jobs. The spooler
need not be shut
down while you edit this file, since it reads the file
a job is printed. (Of course it would be prudent to
shut down the
spooler, just in case you make mistakes while editing.
But when you
want to experiment, it's useful to be able to do it
Guts: The Print Client
In the world of workstations, most computers are print
must send spooled jobs elsewhere for printing. Each
print client runs
a daemon (lpd for BSD, lpsched for System V) that
handles the transmission of the print job to the remote
These daemons also handle the communication required
to check remote
spool queues and cancel jobs on the printer hosts.
The /etc/printcap file tells BSD systems where the remote
printer is located (or at least where to send the print
job for further
handling). System V systems have a set of configuration
each printer that hold the same information.
The BSD spooler system runs a master lpd daemon that
a socket for local and remote requests. The master daemon
daemons to handle each request. Print jobs are spooled
directories for each printer. Each job consists of at
least a cf*
control file and a df* data file. Print job format conversions,
accounting, and logging are always done on the printer
fields in the /etc/printcap entry are ignored on a print
The System V spooler under Sun Solaris 2 can be set
up to communicate
with BSD spooler daemons (or printers masquerading as
such). The entries
in the /etc/lp/Systems file define whether to use the
V or the BSD protocol when communicating with a printer
the spooler does understand the BSD lpd protocol, you
configure all your print clients and hosts to use the
for communication if you find this to be more reliable.
with BSD spoolers, the Service Access Facility listen
must be configured to listen for both S5 and BSD requests.
makes these requests available to the lpsched daemon
Guts: The Printer Host
Jobs originating locally or received from print clients
in essentially the same way on the printer host. Both
and the lpr commands have options to print a file without
making a copy in the spool queue, but that applies only
to jobs actually
spooled on the print host. Jobs from clients are always
the spool space on the host, so this space needs to
be large enough
to hold all queued jobs. PostScript files containing
especially color graphics, can be very large. For this
reason I set
several hundred megabytes aside as spool space.
A major complication of printing is that the print job
may not be
in the "language" the printer speaks. Send
an ASCII file to
a PostScript printer and nothing will print. Send a
to a printer expecting the HP PCL language and the file
as an ASCII file showing the PostScript language and
a binary file to a lineprinter and you may get thousands
of garbage. Appropriate filters need to be installed
on the printer host to translate print jobs into the
The Adobe TranScript package is often used to convert
files to PostScript.
Some conversions are automatic, such as text to PostScript,
some must be explicitly requested by the user. There
may be a command
outside the spooling system for doing the file conversion
example, using dvips to do the conversion from TEX
dvi to PostScript. Users of graphics packages generally
PostScript as an output format.
Printer accounting and logging is done on the BSD printer
enabled in the /etc/printcap file and supported by one
the printing filters. Out of the box, the System V spooler
implement printer accounting, but it does keep several
log files in
the /var/lp/logs directory.
Note that accounting is not a simple task. Often only
knows for certain how many pages or sheets were printed,
so a dialog
with the printer is needed after the job has been printed
accounting information. Even then it may be impossible
to tell if
the user printed on, say, expensive overhead transparency
of on recycled paper.
Guts: The Printer
Finally there is the task of sending the print job to
hardware. This may involve using a serial or parallel
or forwarding the job on to a printer sitting on the
a printer may itself be quite a smart box, the dialog
printer host and the printer is usually quite stupid.
host cannot determine what the printer is really doing
and has a limited
set of commands for controlling the printer. Because
the same connection
is used to send the data and the commands, the host
may not be able
to get the printer's attention when something goes wrong.
Using Both Spoolers
Given that you have solved the separate problems of
making your BSD
systems work well on their own and your System V systems
on their own, exchanging print jobs is easy to do. Most
System V spoolers
know how to talk to BSD spoolers, so this is just a
matter of configuration.
Printer accounting is done by the BSD printer host.
If you hang a
printer on a System V machine, don't expect to be able
Conversion of a print file to PostScript is generally
done on the
printer host if it is not done explicitly by the user.
Make sure all
your printer hosts are capable of the same set of conversions.
Techniques, Tricks, Problems
A number of vendors sell printers that sit directly
on the network
and speak the BSD spooler protocol. There are boxes
you can buy for
$1K or less that have a network connection on one side,
port on the other side, and speak the BSD spooler protocol.
throughput and isolates the printer from whatever is
a particular UNIX machine, but may make it difficult
to talk directly
to the printer to recover accounting information.
CAP (Columbia AppleTalk Package) is available by anonymous
ftp.columbia.edu. The package is a general solution
a UNIX machine interact with an Apple Macintosh, but
a small part
of it makes it possible for a UNIX machine to talk to
a printer that
is on an AppleTalk network. I've used the package with
SunOS and it
is reported to work with Solaris. Be warned, though,
that CAP can
be difficult to install if you know nothing about AppleTalk
you may need additional network hardware to do the routing
your TCP/IP on Ethernet and your AppleTalk-on-Ethernet.
When setting up multiple network printers accessed from
a BSD host,
be careful with the printer locking. The capability
usually specified as ":lp=/dev/null:" explicitly
the device while data is being transferred to the printer.
printer can cause /dev/null to be inaccessible, with
results. If you specify two printers with the same entry
in that field,
only one of them at a time will receive data. So create
object, like /usr/spool/lp1/lockobj, for each network
It is common to hang printers on workstations to get
them out of the
machine room. You may need to use NFS-mounted spool
space to do this.
Watch out for the root-over-NFS access problem and make
spool space is mounted as writable by root. Also watch
out for problems
with the GID used to access some of the files. The GID
between BSD and System V spoolers.
Printer and spooler log files can mushroom in the blink
of an eye
when something goes wrong. Use cron jobs to frequently
out these files. You rarely need to keep log information
long unless you're using the log to recover accounting
When printers or printer hosts are down, spooled jobs
build up on workstations and exhaust the queue space.
When you bring
the printer or host back online, these jobs may all
print, even though
users in the interim printed their jobs elsewhere. It
is a serious
deficiency of both spoolers that there is no way to
manage the log
files and spool space distributed on machines around
Listing 1, a user command I call lptek, is a perl script
control the options on a Tektronix Phaser III PXi printer
PostScript control code to the job sent to the printer.
code is supplied with the printer and is not included
in the source
listing.) This general approach can be used to set options
PostScript printers. The script also writes an accounting
with the BSD pac accounting command.
Listing 2, a perl script I call mypac, is a replacement
the BSD pac command. This is not an exact replacement,
does only what I want in terms of printer accounting.
You can use
this script with either the BSD or the System V spooler,
as long as
you are writing pac-style accounting records. See the
in the script for the simple format of these records.
The sidebar ("Using the SunOS 4.1.2 Spooler under
and Listing 3 and Listing 4 describe how
have installed the
BSD spooler binaries on many of my workstations running
We had a number of problems with the spooler under Solaris,
through patch level 9. Eventually I gave up on it, installed
binaries, and moved my heavily used printers to network
or BSD hosts.
Which Should You Use?
After all I've said, is there a good reason to choose
over the other, if you have a choice? My experience
has been that
the BSD spooler works better and interoperates better
with other spoolers
and network printers. It has the hooks built in to do
and a program (pac) to generate reports. The availability
of source code is a big plus for me.
The System V spooler holds promise, if you are willing
some effort into making it work. It supports classes
forms management, flexible specification of printer
filters and interfaces,
and has a richer set of system administration commands
such as redirecting jobs already spooled. It has a more
feel to it. Out of the box it does not provide printer
but this is relatively easy to add yourself.
Printing, as represented by the BSD and System V spooling
is still in the dark ages of one or two slow lineprinters
to a big computer. Printers themselves have grown quite
LaserWriters run for years, printing over 100,000 pages
need an overhaul), but neither spooler is really what
we need in today's
world of workstations and network printers. Better things
are, I hope,
Author's Note: I wish to acknowledge my fellow system
at MSU and on the net. I would not know what I know
or be able to
do what I do without the help, information, and tools
in this community.
About the Author
John Lees has an M.S. in computer science and has worked
the past twenty years as a teacher, technical writer,
programmer, and system administrator. His computer experience
in the days of front panels and paper tape, and he doesn't
fingers and toes to count the operating systems he has
used. His love/hate
relationship with UNIX dates to early 1985. Currently
Mr. Lees is
a systems analyst with the Department of Computer Science
of the Pattern Recognition and Image Processing Laboratory
State University. He is a member of ACM, TUG, and the
System Administrators Guild. You can reach him at email@example.com;