lp spooler

[Patrick Williams_1]

What exactly is happening when the lp command is given? As an example:
lp -ddog1 fish.txt

What directory contains the file used to spool the "fish.txt" and set it up for printing? What directory contains the device "dog1"? How is "dog1" related to a real device or port?

I am attempting to trace the flow of the output from the source file, through the spooler system and then to the final output device because somewhere along the way it seems to be prepared for an output device that was not the one specified; i.e., the output contains unprintables, page ejects and overstrikes.

[Uday_S_Ankolekar]

Check
/var/spool/lp directory.

-USA..

[A. Clay Stephenson]

Well, that's a big question. I'll at least get you started. Look under /var/spool/lp. You will see an interfaces directory and that will have a file named dog1. It's almost always a shell script but it handles the command to actually print the file(s). There is also a direcory named request; it will have have a directory under it named 'dog1' as well and this is where the actual request data is stored.

Now here's where things get a little tricky.

suppose that you did this:
lp -ddog1 fish.txt
sleep 300
rm fish.txt

You think 300 seconds is plenty of time for whatever it is that lp does and that it should be okay to rm fish.txt. The answer? maybe. The actual file 'fish.txt' is not copied by lp; it only knows the name of the file.

However,
lp -ddog1 -c fish.txt
rm fish.txt
or
cat fish.txt | lp -ddog1
rm fish.txt

will work perfectly because the data itself is copied or at least is open so that rm will remove the link but will not actually delete the file itself until all file descriptors which had fish.txt open are closed.

Man lp* for details.

[Sean OB_1]

/var/spool/lp contains the spooled files.
/etc/lp/interface should contain the files for each printer.

Most likely have the wrong driver setup for the printer. Check to see what is setup in /etc/lp/interface/ddog1.

[Sean OB_1]

oops, obviously it should be /etc/lp/interface/dog1 not ddog1.

[Dave Chamberlin]

The /etc/lp/interface dir contains a file named for each printer. This script is run when the job prints. For many of my printers, the output is not right unless the line with PRINTERCFG= has nothing after the =. The subdirectory model.orig in interface contains a file for each printer - this has the model info that the printer was configured with. This is one thing SAM doesn't show. You can see if this is set to the wrong type of printer by doing a head on the file.

[Sean OB_1]

Patrick,

Just a reminder to give points out to those who answered your questions. It only takes a moment, and helps make the forums more useful to everyone.

Sean

[Geoff Wild]

Here's some info for you as I had to go through it all as we run printing as as package in MC/ServiceGuard:

/etc/lp Directory of spooler configuration data
/var/sam/lp Backup directory of spooler configuration
/var/spool/lp Directory of LP spooling files and directories
/var/adm/lp Directory of spooler log files


Here's a script to check printer status:

#!/bin/sh
#
# check printer status
# Geoff Wild

if [ $# -lt 1 -o \( $# -gt 1 -a $# -lt 4 \) ]
then
echo "Usage:"
echo "lpst \"printer\""
echo "Example:"
echo "lpst W052"
exit 1
fi
echo " "
/usr/sbin/ping $1 -n 2
echo " "
lpstat -p$1 -v$1
echo " "
echo "Output Requests"
echo "-----------------------------------------------------------"
lpstat -o$1
echo " "
lpstat -r
echo " "


As far as your question:

lp -ddog1 fish.txt

fish.txt (if it exists) is submitted to the queue dog1. The file is copied to /var/spool/lp/receive.

/etc/lp/interface/dog1 is the model script used to print the file.

The actual device? /dev/null unless it is remote. But I assume the "actual" device. Well, device should have an ip address - if you are using HP printers with Jet Direct cards, then:

/opt/hpnpl/bin/hpnpadmin -v dog1

That should give you some details.


Rgds...Geoff

[Bill Hassell]

Here's an overview of lp:

lp doesn't print anything. Instead, it checks that there is an accessible file to print and that the printer is accepting requests (disabled printers can still accept jobs). If that's true, lp will copy the file to /var/spool/lp/request/ creating a datafile and also a control file. Then, a token is dropped into the FIFO file and lp terminates.

Now, the first lpsched (parent is init) reads FIFO and schedules another lpsched to run the print job. This lpsched reads the control file, looks in the pstat file for details about the printer and then schedules a printer script (often called a driver but not really) which then sends the print job to the printer.

What makes all this complicated is the very wide variety of printer connections: serial, parallel, JetDirect, remote. So you can see a print job in the /var/spool/lp/request directory.

Now formatting errors are almost always due to a mismatch between the file type and the output method. HP-UX performs no re-formatting when sending data to a remote system. This is likely your problem. HP-UX will translate ASCII so there is a CR/LF pair but only for local printers. The postscript model will translate plain ASCII but will not translate Postscript into PCL or vice versa.

Perhaps a description of how the printer is connected will help. And a model number for the printer will help.