Large print request corrupts spooling to that printer

[Ed Hon]

On HP-UX 11.00, a user accidentally sent a large output (1,200 pages) to a network printer on an HP Jet Direct Print server. The printer stopped, and using SAM I found the print request and cancelled it. Printing did not start on that printer, so I disabled and enabled the printer, also without success. It wasn't until I restarted the spooler that it started printing again. None of the other printers were affected. Why was it necessary to restart the spooler and was there a better way of handling this situation? TIA.

[Alan Riggs]

The easier way to do it is simply:

cancel (print_job) from the command line. This should have no impact whatsoever on other jobs in the queue.

[Russell Gross]

Forget SAM -- too slow. Quickest way is

>lpstat

. . . this will list jobs (first column is job ID)

Then . . .
>cancel to remove the job.
(also, >cancel -e kills ALL print jobs for the printer -- very handy)

I've run into this situation before, where one printer will not print until lpsched it restarted. Doesn't affect other printers. Try
>lpshut (shut down scheduler)
>lpsched (restart it). You may need to specify path to correct scheduler (/usr/lib/lpsched) on your system.

[Mark Mitchell]

Basically what he said is the case. Sam could be killing more than you think. At the command line type "lpstat -o" you can pipe it to more if you have to or
"lpstat printername". that will give you the information that you need for the command above. Plus if the user fired off the print more than once "cancel printername -e" will cancel everything in that printer queue.

[Alan Riggs]

The problem with recycling the scheduler is that it can cause other jobs in the queues to start printing from the beginning again. With a print server that has a large number of queues this can be very inconvenient. It does have to be done sometimes, though.

Before recycling, always try:

accept (queue)
enable (queue)

Also, ps -ef|grep lpsched
You may see several processes (there will be one for each active print job) but they should all be children of a single parent. I have sometimes seen multiple "parent" lpsched processes. Kill the extraneous ones manually and then try recycling the queue. Only if that fails recycle lpsched.

[Vincente Fernandes]

The easiest thing in your case is to find and cancel the request belongs to that particular printer. It will take some time to stop printing since some data is already buffered in the printer memory. Another way is to disable the printer/queue and then cancel the print request. All this can be acheived very easily through command line and with more control and less time. Always do not stop printer spooler unless and until it is required as there are chances of effecting other printers