Ticket #484 (closed defect: wontfix)

Opened 12 years ago

Last modified 10 years ago

Job not canceled when removed from queue

Reported by: pweaver Owned by:
Priority: normal Milestone: The Distant Future
Component: -- Keywords:
Cc: Fixed in version:
Upstream bug:


When a job is removed using lprm and it is the active job the job still continues to print even when it is removed from the queue and the printer is restarted.

Change History

comment:1 Changed 12 years ago by jdreed

  • Milestone set to The Distant Future

I'd be interested in seeing if this behavior is dependent on the size of the job.

comment:2 Changed 12 years ago by geofft

This may be a tangential issue, but according to the CUPS documentation, the server should be waiting for the job to terminate (much like LPRng always did) unless we specify ?waiteof=false in the queue URL, which we don't.


But in my experience this isn't what's actually happening.

comment:3 Changed 12 years ago by jdreed

nless we specify ?waiteof=false in the queue URL, which we don't.

expn "we" -- Are sure this isn't enabled on the CUPS servers?

comment:4 Changed 12 years ago by geofft

 http://get-print.mit.edu:631/printers/ajax says

Connection: accsnmp://socket://AJAX-P.MIT.EDU:9100

comment:5 Changed 11 years ago by jdreed

The bounce queues specify ?waitprinter=false&waitjob=false. I wonder if something awesome is happening here, although lprm should be talking to the real server. I'll note that with CUPS, the Cancel Job button on the printers actually works. So maybe the right answer here is "WONTFIX".

comment:6 Changed 10 years ago by jdreed

  • Status changed from new to closed
  • Resolution set to wontfix

I tested this. waiteof will wait for the job to terminate as far as the printer is concerned. Modern printers cache the entire job in RAM and say "OK, I'm done" when they're not. So CUPS has passed the job on. And I think lprm has worked, but too much of the job is now cached on the printer, so it keeps printing. Using the printer's "Cancel Job" feature is the right answer here.

Note: See TracTickets for help on using tickets.