[lug] Cancel Print Jobs on Remmote Printers, How To Do It?

Ryan Kirkpatrick linux at rkirkpat.net
Thu Sep 28 13:05:04 MDT 2000


	WARNING: Long detailed explanation of network printer problems
below. If you just want to see my specific question, jump to the last two
paragraphs. 

	I am attempting (at work) to streamline the printing to remote
printers from a central Linux server. The one part I am running into
trouble with is how to kill an active print job as easily as possible.
Currently we have two types of remote printers, HP Laser-jets with
Jet-Direct cards, and Intel NetPort XLs hosting Epson dot-matrix printers.
Both support LPD printing.
	The current configuration involves simply defining the remote
printers in /etc/printcap with the 'rm=' option. When one prints with lpr,
lpr will block (i.e. not return) until the entire print job has been sent
to the remote printer, which often can not happen until a significant part
of the job has actually been printed. Now, if I attempt to cancel the
print job with an lprm command from another shell while lpr is blocked,
lprm reports a connection refused message and gives up. This happens with
both types of remote printers. I get the same error in trying to run lpq
against the remote printer as well.
	The new configuration I am developing uses pseudo printcap entries
for the remote printers that call a custom 'if=' script when a job is sent
to them. This script does a bit of error checking (like not sending
graphic files to the dot matrix printers :), and then forwards on the job
to the remote printers directly via the 'rlpr' command. RLPR is a handy
little program that can print directly to a remote printer queue w/o any
local configurations, just command line options. 
	In this case, when I run lpr to send a print job, lpr returns
immediately and running lpq shows the job queued on the local server until
rlpr has sent all the data to the remote printer. Advantage here is I have
more control of what type of data goes to what printer, and spooling of
multiple print jobs can occur locally where there is more space than
remotely where there is very little space at all (i.e. memory cache only).
Now, if I cancel an active print job, the filter exits immediately and the
job disappears from the queue. But, the printer keeps printing what data
it has already received.
	Now, to actually stop the active print job: For the HP LJs, I have
to go over and press the cancel button physically on the printer and wait
for a few more pages to spit out before it stops. For the Netports, I have
to pause the Epson printers, go a Windows box :(, bring up Intel's netport
manager software, wait for it to find the netports, select the offending
netport, instruct the manager to reset it, go back to the Epson printer
and clear its internal buffer.
	Now, the new configuration appears to be better and more
responsive than the old one, and appears that I could (at least
theoretically) kill more of a active print job quicker, and waste less
paper/ink/toner by letting what did get sent print on out. But what I
would like to be able to do is send some command or signal to the remote
printer that the current job is to be canceled. The printer would stop
receiving data, causing the sending rlpr to error out with a useful error
message. I already have the support in the filter to email rlpr errors
back to the user, and this way they would quickly realize that they had
succeed in killing the print job. 
	So, my question is, is this possible? And if so, how do I send
this command to tell the printer to stop dead in its tracks? If it is not
possible, does anyone have any other ideas on how to approach this
problem? Thanks for you help in advance. TTYL.

---------------------------------------------------------------------------
|   "For to me to live is Christ, and to die is gain."                    |
|                                            --- Philippians 1:21 (KJV)   |
---------------------------------------------------------------------------
|   Ryan Kirkpatrick  |  Boulder, Colorado  |  http://www.rkirkpat.net/   |
---------------------------------------------------------------------------





More information about the LUG mailing list