[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Woody & CUPS - jobs won't die



I've had this little problem on a couple Woody systems.  Both using all 
stable with the the latest stable CUPS/GimpPrint packages, and kernel 2.4.20. 
For printing, it works perfectly to 2 printers on the Debian box, as well as 
3 printers attached to Windows machines. The problem is in killing jobs.  
Using either the web interface, or via the commandline as root, a queued job 
appears to be killed and removed from the queue.  However the job will 
continue to try to print.  Initially, with jobs already started printing, I 
thought perhaps that the printer's buffer is where the supposed dead jobs 
were originating. But even with several jobs in the queue, and killing a job 
that was far down in the queue, when it's turn comes, it will still print.  
The web interface and lpq will not list the job once it's been removed, but 
it hangs in there somehow.  The only way I've found to kill a job 'good and 
dead' is to go into the Cups spool directory, determine which files are 
associated with the previously killed job, and manually delete them.  
Sometimes a reboot of the server is also require to keep the 'ghost' job from 
printing.  I've removed, purged, and reloaded All Cups associated packages a 
number of times, and even tried going back to the standard lpr/lprng world, 
then replacing them with Cups.  The old lpr/lprng does seem to kill off jobs 
as expected, but Cups seems to resurrect them.  I posted messages in the 
Cups/EasySoftware lists, but no answers there, other than it must be 
something Debian or kernel related.  
The printers affected are HPLJ-4's, HPLJ-3's (yeah, antiques) and a couple 
Epson Color 400's.  The setup and maintainence of all these printers is a 
breeze with Cups and the GimpPrint drivers, so it is much preferred over the 
old standard methods.  But if a job needs to be killed, it's cumbersome to 
have to jump through all the hoops to get it killed.  Any ideas or 
suggestions are greatly appreciated.

Charlie



Reply to: