Basic Principles of Printing in Solaris 2.6 and Above

Print-friendly Version

Introduction

Solaris 2.6 delivered a re-engineered print subsystem that improved and changed the product that had been with us until Solaris 2.5.1. These changes have resulted in much confusion as to what is supported and what is not. There's also uncertainty in figuring out the best way to create and maintain a reliable print server. Customers use a variety of methods to maintain their print servers, with which they may be very satisfied. However, if these methods are not supported by Sun, it can be very difficult to diagnose and fix issues.

The purpose of this document is to provide a simple guide on how to create and administer print servers and clients. One highlight is the troubleshooting section, which will help you locate exactly where your printing problem occurs and how to go about fixing it. The article will also help you gather the information you'll need before logging a call with the Sun Solution Center (see listing at end of article) -- which can really speed up the problem-solving process. A few basic definitions are included for clarity.

Basic Definitions

• Print Server or Spooler
  The machine which manages the print queues. It will have a local device defined (this includes /dev/null) and is responsible for all the local spooling before it sends the job to the printer itself. Thus the print server should contain sufficient storage to spool the entire job(s). It has an operating system installed with its own print scheduler software. The server can be a Solaris box, a PC or any kind of print-spooling device. Don't confuse this definition with devices such as Axis Print Servers, Intel Netport or JetDirect Devices. These are not "true" print servers as per the definition above. It is best to consider these as printer network interfaces.
• Print Client
  The machine where the print job is submitted. Again it can be a Solaris, Linux, NT, Novell, Win2000 or other system. The Solaris model uses client/server techniques that allow the print server to be its own client.
• Local Printing
  This refers to issuing a print job while logged in on the Print Server.
• Remote Printing
  This refers to issuing a print job while logged in on a Print Client. The print job will be forwarded to another machine to be processed before it goes to the printer.
• Network Printing
  Here the printer has a network interface and will have an IP address/hostname which can be "pinged." The print server in this case is the workstation which manages the queue and spools the print job to the network printer.
• Print Scheduler
  The daemon or process which manages the print jobs as they are received and processed. It is known as lpsched in Solaris.
• Interface File
  A shell script that is often responsible for interpreting any print options and preparing the document, and perhaps banner pages, to be sent to the printer. By default, it exists in /etc/lp/interfaces.
• Printcap File
  The traditional BSD printer configuration file. All print queues (local, remote or network) are configured here. This file does not exist in the Solaris print subsystem and is not supported by Sun.

Common Myths

Myth: Port monitors are required to print.
FALSE- You do not need port monitors.
Myth: Use admintool to create all print queues.
FALSE- Creating queues to network printers using admintool is not supported.
Myth: Printing to network printers has always been supported.
FALSE- Printing to network printers has only been supported since Solaris 2.6.
Myth: Client-side filtering (double spooling) is a supported solution.
FALSE- Client-side filtering (double spooling) is NOT supported.

Configuring Print Servers ... or ... How Do I Print to a Network Printer?

This section will explain the creation and management of print servers. Remember that a printer can be directly attached to the workstation/server via the parallel port, the serial port, the USB port and over the network. On average, it appears that most printing problems involve printing to network devices, including those with onboard network cards and those which print via an external printer network interface box. Bearing this in mind, this document will be restricted to printing to network devices because of the large amount of ambiguity among users.

A Basic Network Printer Queue

To create a print queue which prints to a network printer use the following syntax:

# lpadmin -p banana -o protocol=bsd,dest=hostname -v /dev/null
-m netstandard -T unknown -I any

# enable banana

# accept banana

There are a number of important things to notice in this syntax:

1. A print protocol must be specified. BSD is used in the above, but it can also be TCP (to print raw data to a printer).
2. A destination is required; hostname refers to the hostname or IP address of the network printer.
3. The device for a network printer is /dev/null.
The generic printer interface/model supplied by Solaris is the "netstandard" file as specified by the -m option.

The print queue needs to be enabled and accepted in order to print successfully. In essence, this is all you need to do to get a print job printed. You might see one of two things when you print to a queue setup like this: the banner page and job will print successfully; or the banner page will come out fine but the print job will have carriage return/line feed problems. Either of these results is positive and shows that the printing mechanism itself is working fine. The carriage return/line feed problems will be addressed later.

A Basic Network PostScript Printer Queue

# lpadmin -p banana_ps -o protocol=bsd,dest=hostname -v /dev/null
-m netstandard -T PS -I postscript

# enable banana_ps

# accept banana_ps 

An important observation in this example is:

1. The printer type (-T) is now PS
2. The content type (-I) is now postscript

For a network printer, the printer type (-T field) can only be unknown or PS to make a difference. Traditionally, with locally attached printers, the device would be something like /dev/bpp0 or /dev/term/a. This means that when we select a content type such as hplaser or ibmproprinter, appropriate escape codes are sent to the printer port to instruct the printer on how to format the pending print job. However, in the above setup the device is /dev/null; if the -T option is changed, it will not influence the appearance in the final print job. The idea here is to resist the temptation to play with the -T or -I options at this point. You can tinker a bit more with these options after reading about filters later in the article.

Using Third Party Software to Create Queues

These applications are normally supplied by the printer vendor. For example JetAdmin/JetDirect print installer for UNIX is Hewlett-Packard's "queue creator" software for Solaris. It will include all the necessary interface files for all printer models they supply. The installer will also execute the correct lpadmin command for Solaris to make sure a working queue is created. It is a nice little piece of software and we've rarely had any issues with it.

Markvision is Lexmark's application and, similar to JetAdmin, runs the appropriate lpadmin command and puts in the right interface file for the printer you are trying to configure.

Sun's position on this is to always use the vendor-supplied application to create the print queues. This is because it will probably supply the exact interface file to make the most of your printer's features (that is, duplexors, multiple trays, different font sizes and styles, etc.)

What About a 'Print Server'/Printer Network Interface Device?

With the exception of JetDirect print servers, the best way to configure these devices is by using the standard Solaris commands. The majority of the proprietary software supplied for these devices often discusses commands used in pre-Solaris 2.6 terms. These manufacturers are now in the process of updating their documentation and applications.

The key here is to find out what port name or port number you need to print to. For example, to print to an ASCII print queue on an Intel Netport device with no carriage return/line feed problems, you need to print to port mappings LPT1_TEXT (on parallel port 1) or LPT2_TEXT (on parallel port 2).

The correct syntax is as follows:

# lpadmin -p banana -o protocol=bsd,dest=intel-ps:LPT1_TEXT 
-v /dev/null -m netstandard -T unknown -I any

# accept banana

# enable banana

Note that intel-ps is the hostname or IP address of the Intel Netport box as defined in the name service. This port mapping definition varies with each "print server" device. For example, the corresponding port name on an Axis 5600 network device is "pr5"; therefore, the lpadmin command looks like this:

# lpadmin -p banana -o protocol=bsd,dest=axis-ps:pr5 -v /dev/null 
-m netstandard -T unknown -I any

If you need to print PostScript via these print devices you will need to print to another appropriate port. This will be discussed in more detail in a later section on tackling PostScript files.

Configuring Print Clients

There are a couple of utilities you can use to create print clients:

1. Admintool -- to be used for Solaris 2.6 and Solaris 7
2. The printmgr utility in Solaris 8 (in /usr/sadm/admin/bin)

However, they both execute the same commands:

# lpadmin -p banana -s server!remote-queue

Note that:

• banana is the queue you are creating to print to on the client.
• server is the machine you are sending the print job to.
• remote-queue is the name of the print queue on the machine you are sending the print job to.
• If the remote-queue is the same as the queue you are creating on the client then you won't need the !remote-queue part of the command.

Since Solaris 2.6, you do not have to use the lpsystem utility to define remote print servers nor do you have to enable or accept the new client-side queue. There is nothing else to it.

The Print Mechanism

Things work a little differently on a print client than on a print server. One of the primary things to be aware of is that when the job is submitted, it is briefly spooled to /var/spool/print before it makes its way out on the network to the print server. Note that this is different for a print server, where jobs are spooled to /var/spool/lp.

A second difference is that from Solaris 2.6 and above, only the BSD/LPD protocol is used to send print jobs to print servers; no other method is used (pre-Solaris 2.6, the lpsystem command was used to allow a print client to communicate using either System V or BSD).

Banner Pages

This is often an area of confusion especially with network printers that have onboard network cards. You can create a print queue to a network printer, and when you send a print job you can sometimes get up to three banners printed.

What you should notice first is that the banners may have subtle differences in appearance. A Solaris banner will look like this:

#########   User: alices@hostname
##### Title: /etc/release
#####  Date: Fri 17:23 Sep 07, 2001
#####   Job: banana-286
#####

This banner page is produced by the netstandard interface file. Any other banner of any other design is not being produced by the Solaris print subsystem.

You can produce banners via an application or more likely by the onboard network card of a printer. You can disable this from the printer's own display panel, connect to the printer via a web browser (by hostname or IP address if http is enabled on the card) or even by telnetting to the network card itself. It is a simple procedure -- consult the vendor's documentation for further details.

Solaris banners can be manipulated in a variety of ways:

1. When the printer is created for the first time. In my experience it is better to follow the syntax below when putting in banner information at this stage (note I have included 2 -o entries):

# lpadmin -p banana -o protocol=bsd,dest=hostname -o banner 
-v /dev/null .....

This means that the banner will be permanently enabled; a regular user will not be able to disable it. However, the root user can disable the banner.

# lpadmin -p banana -o protocol=bsd,dest=hostname -o nobanner 
-v /dev/null .....

The banner is optional and can be disabled at the user's discretion as they submit a print job:

# lp -d banana -o nobanner ......

The above syntax will prevent a banner from being printed.

2. To edit a queue already created:

# lpadmin -p banana -o banner [banner enabled permanently]

Or

# lpadmin -p banana -o nobanner [banner can be suppressed by user]

3. From the netstandard interface file itself: You need to edit the interface file for the print queue in question. For example:

/etc/lp/interfaces/banana

Note that banana is the name of the print queue you are using. Within this file you will notice the entry:

nobanner="no"
Thus to disable the banner, you must change this to:

nobanner="yes"
This actually means "yes, I do not want a banner." It can get rather confusing! The final step takes precedence over the former two methods.

For Solaris 8, 9 and above, there are some undocumented ways of configuring banner pages.

Create a print queue as normal, but check out the new banner syntax:

 # lpadmin -p banana -o protocol=bsd,dest=hostname -o banner=always
 -v /dev/null .....

There are three options you can select:

• banner=always - This means that the banner is always on and can only be overridden by root.
• banner=optional - This means that the banner can be selected to print or not and can be selected by all users.
• banner=never - This means that the banner will never be printed and can only be overridden by root.

This new feature means that it is now unnecessary to edit the interface file to prevent banner pages from being printed. The best way to understand which is best for your particular situation is to test all the configurations and get a feel for what works with what. This new feature does not apply to pre-Solaris 8 releases.

Printing to a PostScript Printer

You should think of PostScript printing in a slightly different way than using ASCII print queues. As previously discussed, the big difference with PostScript print queues is that the content type is postscript and the printer type is PS. When you set these options, remember that lpsched handles the file translation from ASCII to PostScript. It does translation via the postprint utility which exists in /usr/lib/lp/postscript/postprint. A significant point is that once the job is translated, it is spooled to the printer directly. It is then up to the printer to interpret it.

It is important for you to determine if your printer has PostScript capabilities and which versions of PostScript it will support. At the time of writing this document, there are three versions (Level 1, 2 and 3). Your printer vendor can confirm this for you. As a reference, on Solaris 8 10/00, the postprint utility provides a PostScript level 2 document.

After lpsched has converted or "filtered" the print job to create a PostScript document, it is passed to the printer, untouched. The document should not need any further conversion before it reaches the printing device.

There are two scenarios when you print to a PostScript-enabled printer:

1. You have an ASCII file to print.
2. You have a PostScript file to print.

The appropriate queue configuration depends upon the nature of the source file you are printing. For example, if you have a PostScript printer but have ASCII files to print, you may want to have the files converted to PostScript in order to get them printed correctly. Otherwise you may (not always) see carriage return/line feed ("stair-stepping") problems. Thus, the following is required:

# lpadmin -p banana_ps ...... -T PS -I postscript

As has been noted previously, it is lpsched which will call utilities to manage the ASCII-to-PostScript conversion. If it already detects a PostScript file, it will not have to do any converting, and the job will get spooled and printed as normal.

When printing to a PostScript printer attached to a small printer network interface device, be careful when selecting which port to print to. For example, to set up a queue on an Intel Netport device on parallel port 1, the syntax is as follows:

# lpadmin -p banana -o protocol=bsd,dest=hostname:LPT1_PASSTHRU 
-v /dev/null -m netstandard -T unknown -I any

These so called "pass-through" ports mean that the print job sent to this particular queue will not undergo any kind of filtering or converting. The printer will receive the job as is. If there aren't any issues with the PostScript file itself, it will print successfully. Be sure to check with the documentation of the print server to discover which port has this kind of functionality.

Filters and Filtering

Filtering is a way to manipulate a print job before it leaves the print server. Filtering usually includes a command or script that causes extra formatting codes to be either prepended or appended to the file in order to print it a certain way.

For example, if a print job appears to have carriage return/line feed problems, it can be resolved by passing it through /usr/bin/unix2dos before you send it to the printer (see Troubleshooting Printing Problems). The fact that you're using unix2dos means that you have filtered the job before printing.

In a more demanding environment, a printer may have many functions ranging from different page orientations to different paper trays and fonts. More often than not, printer manufacturers will supply proprietary software to help you configure the printers to get the most out of them such as JetAdmin/JetDirect Print installer for UNIX (HP), Markvision (Lexmark) and CentreWare (Xerox). These are quite robust applications and, from personal experience, work well with Solaris.

If you do need a filter, it is recommended that you work with proprietary software first to see if it will do the job for you. Solaris provides only a basic interface file which allows you to print documents reliably. It would be impossible to design a multitude of interface scripts for all the printer makes and models available on the market.

Many customers call into the Sun Solution Center (see listing at end of article) asking for assistance to design or write filters to help provide a workaround to a problem. Custom filters are actually a workaround in resolving a particular printing issue and are not supported by Sun. However, Sun can provide some advice as a courtesy if this is the only solution to the problem.

In order to write a filter for your printer, you have to know what language it interprets. For example, HP printers tend to use PCL (Printer Command Language), while others use PostScript (developed by Adobe), and still others use ASCII.

A Basic Print Filter in PCL

There are many PCL references on the Internet, so it is easy to get access to the codes. HP's website is particularly useful, especially in this section:

HP LaserJet Printers -- PCL Commands, Basic Page Formatting, and Font Selection.

The following example shows how to create a queue to print landscapes using a PCL filter:

Note: There are special key sequences to enter these "escape codes" into the scripts. For Solaris, use the key sequence Control+V together, and Esc while in "vi" before you start entering the PCL codes.

1. Create the filter script in a suitable directory, for example: /opt/local/bin:

#!/bin/ksh
#
# /opt/local/bin/landscape.sh
# Example of a script to print landscape using PCL
#

# Put into landscape
# Control + V, Esc, ampersand, lower case l (ell), 1 
(one), upper case O (oh)

echo "^[&l1O"
cat -
echo "^[&l0O"

# Put back to portrait - not always required
# Control + V, Esc, ampersand, lower case l (ell), zero 
(0), upper case O (oh)

Remember to make this script executable; permissions 755 should be sufficient.

2. Create the filter definition file /etc/lp/fd/landscape.fd. Be careful to preserve all spaces within this file:

Input types: any
Output types: landscape 
Printer types: any
Printers: any
Filter type: slow
Command: /opt/local/bin/landscape.sh

3. Register the filter with the lp subsystem:

# lpfilter -f landscape -F /etc/lp/fd/landscape.fd

The -f field needs to match the "output types" entry in the *.fd file.

4. Create a queue with this content type:

# lpadmin -p landy -o protocol=bsd,dest=hostname -v /dev/null -m 
netstandard -T unknown -I landscape

# enable landy ; accept landy

This will create a queue (landy) to a printer (which can interpret PCL) to print a file in a landscape orientation.

The codes within the scripts can be additive. For example, if your queue had carriage return/line feed problems, you could put the appropriate escape code for this before the landscape escape code. For instance:

# Fixing CR/LF problem
# Control +  V, ampersand, lower case k, 2 (two), upper
case g (gee)
echo "^[&k2G"
# Put into landscape
# Control +  V, ampersand, lower case l (ell), 1 (one), 
upper case O (oh)
echo "^[&l1O"
cat -
echo "^[&l0O"
# Put back to portrait - not always required
# Control + V, ampersand, lower case l (ell), zero (0), 
upper case O (oh)

All these codes will prepend the print job so that when it reaches the printer, it will be interpreted and dealt with as instructed.

Care needs to be taken when creating and maintaining filters. They can easily become complex and extremely cryptic. The key is to try to make them as simple as possible. Don't try to do too much. If you find that they are becoming too complex, investigate the proprietary software again. It may be a more manageable and supportable solution.

Client-Side Filtering/Double Spooling

Any type of client-side filtering or "double spooling" is not supported. This means that all the print job manipulations should be done on the print server only. Double spooling is a print queue configuration whereby a print job is filtered on a local queue and then re-spooled to another locally defined queue before it goes to the printer (spooled twice/double spooled). In essence, this is another type of client-side filtering. One of the main reasons this is not supported is because the queue becomes difficult to manage. This is because the final print job cannot be cancelled by the user who submitted the job. By this stage, the job becomes owned by the user lp and cannot be cancelled without root user intervention.

Troubleshooting Printing Problems

When working on a printing problem, it is imperative that you can identify exactly where the problem is. Some of the questions you need to ask yourself are listed below:

1. Where does the problem lie (for example, does it appear on the print client or print server)?
2. What is the problem -- how is it manifesting itself?
3. How extensive is the problem? (For example, does the problem appear on all print servers/clients or only a few?)
4. What make/model of printer am I seeing the problem on?
5. How was the problem queue(s) configured (lpstat -lp queuename)?

These questions sound very basic but they are of primary importance and need to be answered before you can continue to troubleshoot.

Problems on Print Clients

Print-client problems are the simplest to fix, mainly because printing on a client only takes a few steps before the job is sent out to the print server. Also, if there are problems on a client, the chances are that tweaking will need to be done on the print server.

A common symptom is that the job appears stuck on the machine where the job was submitted. It never seems to leave the queue and lpstat -o "queue" shows it's still there. Things to check first:

1. Can you ping the print server?

2. Since you follow the BSD protocol, can you telnet the print server on port 515? If this is successful, you should see something like:

# telnet sun-serv 515
Trying 10.1.2.3...
Connected to sun-serv.
Escape character is '^]'.

Invalid protocol request (13): 

Connection closed by foreign host.

Any other message, especially any "connection refused" message, tells you there is a problem on the print server.

3. Check for a process on the client called printd; is it running?

4. Look in /var/spool/print -- are there any files here? Check the date stamp. Are they new or old?

5. Remember all print client information is contained in /etc/printers.conf -- this is not a printcap file.

If a printd process is running, then there is a problem in trying to contact the print server. What happens here is that the lp process, which is trying to submit the job, forks into printd. The print job itself will remain in /var/spool/print and the parent lp process dies. printd will then try to submit the job at certain intervals until it succeeds. Note: This means that printd should not be running on a print server, but on a print client instead.

For your information, there were a few bugs associated with printd which have all been fixed in the latest lp patches for Solaris 2.6 (106235), Solaris 7 (107115) and Solaris 8 (109320). It is a good idea to keep as up-to-date on these patches as possible. These are non-invasive patches and do not require a system reboot. You'll just need a stop and restart of the printing services (/etc/init.d/lp stop|start).

Problems on Print Servers

There are a few more items you'll need to address when seeing problems on a print server. Remember that all the problem-defining questions listed previously are very important.

Whenever you're experiencing a problem, it is always a good idea to take a look in the print log files in /var/lp/logs/*. There are 2 sets of files there, lpsched and requests. Although the lpsched log file will provide debug information about how lpsched was responding to an issue, do not underestimate the usefulness of the requests file. These files contain status codes which will show if a print job was successful in the early stages, even before it has been spooled.

Pre-Solaris 2.6, there were two printing daemons involved, lpsched and lpNet. Since Solaris 2.6, there is only the lpsched process that is seen in a /usr/bin/ps listing. On a busy system you may see more than one lpsched process running. This is because you see an lpsched process for every queue that is active.

Here is a list of common problems that can occur and how to fix them:

1. Clients cannot print to the print server, but the server itself prints fine.
If the clients cannot print, check if they can telnet to port 515 of the server. If they get a "connection refused"-type error, it could be that the port-listening device, in.lpd, may not be running. Check in the /etc/inetd.conf file for the following line:

#
# Print Protocol Adaptor - BSD listener
#
printer  stream  tcp  nowait  root  /usr/lib/print/in.lpd  in.lpd

This line should not be commented out. This process enables communication on port 515 to allow clients to print. Another problem might be that port monitors have accidently (or purposely) been activated. Check for the following processes:

These are the old printing port monitors. The listenS5 refers to a port monitor for the System V printing protocol and the listenBSD refers to the port monitor for the BSD protocol. However, mentioned earlier, these are no longer required since the in.lpd process is used. When port monitors are running, they can prevent in.lpd from accepting requests. They can be deleted using the following syntax:

# pmadm -r -p tcp -s lpd

# pmadm -r -p tcp -s lp

# pmadm -r -p tcp -s 0

The last pmadm command shows the number zero and not the letter "O".

2. You cannot cancel any print jobs.
This could also be an in.lpd/port monitor issue. When a print job is cancelled, it communicates with the print server itself, on port 515. Check for in.lpd being active in the /etc/inetd.conf file and also check for rogue port monitors in use on the printer server.

3. The print job stays stuck in the queue and never comes out.
This suggests that the problem could be on the printer side. Is the printer switched off or out of paper? Check the obvious things. Also, it could be printing to the wrong printer port -- did this work before? A good place to check for information is in the printer log files in /var/lp/logs/*. If you do suspect some kind of networking issue, then setting up a snoop to investigate the printing problem is recommended. Follow the directions below:

Log onto the Solaris print server as root and then open two xterm windows. In one window type the following, but do not hit enter/return yet:

# snoop -o /tmp/snoop.out [IP address/hostname of Solaris 
box] [IP address/hostname of network printer]

Note that the brackets are not required; they denote your input. Get a job ready to print but do not hit enter/return yet:

# lp -d problem-queue /etc/hosts

Now, hit enter/return in the snoop window, followed by hitting enter/return in the print job window. The print job will be submitted while the snoop is capturing TCP/IP communication between the Solaris host and the printer. Make a note of the request ID of the test print job you are submitting. It will allow you to trace the particular print job, especially if you have a busy print server.

In the snoop window you will see something like this:

# snoop -o /tmp/snoop.out sun-serv hp-printer
Using device /dev/hme (promiscuous mode)
12

The number you see there is the number of network packets captured. This could grow very large, so try to limit the amount of time the snoop is running as the final snoop file will be almost impossible to analyze.

If you need assistance analyzing the printing issue, be sure to log a call with the Sun Solution Center (see listing at end of article) who can assist you. When sending the snoop file in, make sure it is unencoded before it is emailed to preserve its integrity. For example:

# cd /tmp

# uuencode snoop.out snoop.out  /tmp/snoop.uue

It is snoop.uue which needs to be sent to the Sun engineer. If you are ftp-ing from a machine, make sure you use binary mode for transferring the files. With any printing problem not addressed above, it is a good idea to get a truss of lpsched while you are reproducing the problem. This is described below:

# ps -ef | grep lpsched
root   422     1  0   Jun 14 ?   0:00 /usr/lib/lpsched

Get the process-id of the parent lpsched process as shown above. Then attach a truss process to this as shown below. Be sure to include all options as shown; it may seem verbose but it is important in debugging.

# truss -faeo /tmp/truss.lpsched -vall -rall -wall -p 422

While this truss is running, it will be logging verbose information in the file /tmp/truss.lpsched. If you have a busy print server (lpsched doesn't run on a client) it could grow to a huge file size which will be difficult to analyze. Try not to let the file grow to a file size greater than 1-2MB if possible. With the truss running, test the problem command; it could be that you can't cancel the job or you can't submit the job.

Depending on the printing problem, it might be a good idea to truss the problem process at the same time as trussing the lpsched process in order to get more information. In this situation, you would then have two truss files to refer to when trying to debug the problem. The truss files can look a little intimidating, but if there is something happening that cannot be explained, then log a call with the Sun Solution Center (see listing at end of article). Make sure you explain that you are debugging a printing issue.

Problems with the Print Output Itself

What problems are being observed? Is it that the job comes out with some formatting errors? Perhaps the job doesn't come out at all? Maybe the banner just comes out and nothing else? Is it that an error page is printed with some kind of status code?

Below are some of the common problems observed by customers.

1. What do I do about carriage return/line feed ("stair-stepping") problems?

This problem means that the offending print job comes out like this:

# Here is line 1. 
	         # Line 2 starts here,
				      # and so on ...

This effect is seen when printing ASCII files to printers. It can be seen when printing to local printers but it is addressed by specifying the correct printer type (-T option) which then takes in the correct escape codes to send to the printing device. However, for network printers, the device is /dev/null (see earlier) so this approach doesn't apply.

There are essentially three ways to overcome this:

1. If your printer has PostScript capabilities, then set up your printer to convert all files to PostScript before printing. See the section Printing to a Postscript Printer.
2. You may need to alter the print queue you have created (you may be printing to the wrong port on the printer). Printers can have internal ports/queues a bit like print server devices do. See the section What About a 'Print Server'/Printer Network Interface Device?
3. If you are only printing ASCII to this print queue, you can set up a small unix2dos filter

How to achieve this is described below:

Create a filter definition file in /etc/lp/fd called u2d.fd (unix2dos filter file) and include the following in it. Please be careful to preserve all spaces:

Input types: simple
Output types: u2d
Printer types: any
Printers: any
Filter type: slow
Command: /bin/unix2dos -437 

Include the number after the unix2dos command -- it is an important option.

The next step is to add the filter to the filter table by running the following command in /etc/lp/fd directory:

# lpfilter -f u2d -F /etc/lp/fd/u2d.fd

Then you need to associate the existing printer queue that has the carriage return problem with the newly created filter. This is done by the following command:

# lpadmin -p problem-queue -I u2d

Finally test the filter by sending a print job to that printer.

# lp -d problem-queue /etc/hosts

2. When I print PostScript I keep getting PostScript error pages but no print job.

In this case, keep the error page that is printed, as it can tell you what "bad code/character" the printer received.

These types of errors usually indicate that the PostScript interpreter on the printer couldn't understand the source PostScript file. When this happens, generate a sample PostScript file by using one of the the Solaris utilities:

# /usr/bin/mp 
# /usr/openwin/bin/mp
# /usr/lib/lp/postscript/postprint

These can provide a test PostScript file with which you can test out the printer/queue configuration. If these print successfully, check the source file which you are trying to print. A good way to check this is to try to load the file in /usr/openwin/bin/pageview.

This is a strict utility which will either successfully load your document or provide you with the means to see where the problem is by using the feature to browse the source. It is not an editor but it will help in debugging the problem file. However, be aware that many openwin utilities are being phased out after Solaris 8, and this may include pageview.

A reliable method to capture a print job and check its content is to create a print queue which prints to file. You can easily set it up as shown below:

# touch /var/tmp/localq

# chmod 666 /var/tmp/localq

# lpadmin -p localq -v /var/tmp/localq

An error like this may be seen at this stage; do not be alarmed:

UX:lpadmin: WARNING: "/var/tmp/localq" is accessible by others.
             TO FIX: If other users can access it you may get
                     unwanted output. If this is not what you
                     want change the owner to "lp" and change
                     the mode to 0600.
                     Processing continues.

# enable localq

# accept localq

You can disable banner pages if they cause problems. Basically when a print job is submitted, instead of going to a physical printer, all output will be directed to a file (/var/tmp/localq in this case) which can be viewed in "vi" or loaded into pageview to check its integrity.

Finally, there are instances when the PostScript file is fine, but there are still problems printing PostScript. In this case you should focus on the configuration of the print queue. If a PostScript queue is being tested, the printer and content-type options used are probably -T PS -I postscript. Try changing this to -T unknown -I postscript, disabling a particular utility "postio" from being used. This utility sometimes causes problems for some printer models.

If all of the above don't help alleviate the problem, it is recommended that you log a call with the Sun Solution Center (see listing at end of article) and/or your printer manufacturer.

By this point, you will have a lot of diagnostics which will help the engineer isolate the problem.

Conclusions

This document explains how to use and administer network printing. Hopefully, all common pitfalls have been included, and it has explained how to go about isolating the problem. Also you've learned the correct way to create and maintain Sun-supported printing configurations.

In summary, when logging a call with a printing issue, always remember to supply the following information:

Where does the problem occur?
Does it occur for all print queues?
When did the problem start happening?
Is any non-Sun/Solaris application being used?
Provide any error messages which appear on the console, via email, or in the /var/lp/log/* files?
Have the latest printing patches been applied yet?

About the Author

Alice Soteriou is a physical biochemistry scientist by trade in the field of nuclear magnetic resonance spectroscopy and molecular modeling. She worked in academic research for a number of years before taking the full plunge into IT. She is presently based at the Sun Solution Centre (UK) where she has been an operating systems backline engineer for the last three years. She has worked with a multitude of operating system issues, and one of her pet subjects is the Solaris printing subsystem.

Sun Solution Centers

Sun Solution Center - United States
Sun Solution Center - United Kingdom
Sun Solution Center - Germany
Sun Solution Center - France

December 2001 (updated September 2003)