Everything Fit to Print: Solving the Meddlesome Print Spooler Dilemma
Printing is one of those tasks that a sys admin just loves to support. There are printers that always put the toner on the paper, and there are printers that are covered with footprints, from being kicked all the time. Of all the problems that can cause a print process to stop working, print spooler problems can be the most exasperating to solve. Kick the confusion, and get some problem solving tips.
Printing is one of those tasks that a sys admin just loves to support. There are printers that always put the toner on the paper and there are printers that are covered all over with footprints from being kicked all the time. Of all the problems that can cause a print process to stop working, print spooler problems can be the most exasperating to solve.
When printing normal size files with the lp command, success starts when you see the message "request id is printer-1234" on your screen and success ends with a fistful of paper. When printing large files of over 100 Mbs each, success might start with the "request id…" message, but it can easily end with no paper, no toner and more footprints. So, what could go wrong with the print spooler?
If you look at the man page for the lp command and go down to the –c option, you will see, "Normally, the files are linked into a spool directory." This would be the printer’s request directory: /var/spool/lp/request/printer. It leads you to believe that, normally print files are linked and not moved into the spooler’s file system. If this were the case, then /var would never fill up by printing large files because this directory would only contain a link to the real file to be printed. But, the print spooler was rewritten after the man page came out to accommodate applications that need to have their print files copied to the printer’s request directory before the print file is overwritten by the application that created it. The spooler no longer prints from a link to the file. There is no option in the lp command to let you choose between a file link and a file copy. The spooler must copy the entire file to /var … to print it. If your /var is anything like my /var, then you are not going to print too many large files.
/var is always filling up with system log files and other system files without any help from the print spooler. I chased a squirrel through /var once. It took hours to catch it. But, the print spooler does not give you a message that /var is full, or that the print file will be lost. If there is not enough room for your print file in /var, then you will just see the "request id is printer-1234" message and that’s it. /var will fill up and kill the print process – no printout, and another sore foot.
If you want to prove that the print file gets copied to the request directory instead linking to it, then just stop a printer at the command prompt, print a file to it with lp, and then look in its request directory.
After the printer is enabled, the files will remain in /var for as long as it takes for the printer to print them. If the file to be printed is very big, it will remain in /var a rather long time. 100 Mb files can require four reams of paper. Other users might queue up their print files to the printer and … yup, /var gets full. I knew a sys admin who would delete a printer’s queue and recreate it just to solve this problem. He swore this fixed the printer problem, and there was something wrong with the software. What he was really doing was deleting all the print files that were queued up for the printer (when he deleted the print queue) and freed up the space in /var. By the time he told all the users to reprint their print jobs, /var stayed empty long enough to pass all the print jobs through it.
The real solution to the problem of filling up /var is rather simple. Move the printer’s request directory to a different file system where you have the room to accommodate all of your print requests. Murphy’s Law says that all of your biggest print files will hit the same printer at the same time. It might take a Gig of space or more for your print files, but you have to do what you have to do. Leaving this much disk space unused in a file system just waiting for large print files to fill it is a job in itself. It will cause a lot of fighting among your DBAs who want to park their archive files there. So, be prepared for them. You might have to kick the DBAs instead of the printer.
This will do it for a normal HP type printer. But, the story doesn’t end here. If you have a special printer, like a Xerox printer, that is networked, and you installed the print queue with Xerox’s Xpadmin software instead of HP’s Jetadmin, then the story continues (don’t kick the printer just yet). /var will still fill up. If you call HP for help, they will tell you to call Xerox. If you call Xerox for help, they will tell you to call HP. Let me save you the trouble.
Xerox’s printers, like many other printers, install two print spool queues to get the toner on the paper. One print queue feeds the second print queue. The lp command uses the first print spooler queue, which then sends its output to a second Raw print queue which feeds the printer. This second Raw print queue is also controlled by the same print spooler that we have come to love. The spooler then copies its files to … you guessed it … /var/spool/lp/request/_Rawprinter_.
If you have a Raw queue attached to a print queue, you also have to move its request directory to your /more_room file system by creating a link from the Raw printer’s current request directory to your /more_room file system with the same procedure we just did for the lp print queue, or it can also fill up /var.
You have to identify the name of the Raw print queue that is fed by the printer queue that you are fixing. In the case of Xerox printers, you can run xpadmin, select Modify a Queue, select the printer you are looking for, and you will see the name of the Raw print queue. You can not move the Raw queue’s request directory from xpadmin, you can just find its name.
Perhaps, one day, the man pages will tell it like it is. Perhaps, the HP-UNIX Install/Upgrade program of the future will ask us what file system we want to put the request directories into. Maybe, one day, printers will come with rubber panels that say "kick here before adding toner." Supporting printers is fun … don’t you think?