Description of problem: It appears that if a job causes a print queue to be disabled, re-enabling the print queue does not cause the job to get printed and it gets stuck on the queue. Later jobs in the queue do print. Version-Release number of selected component (if applicable): cups-1.2.4-1.1 How reproducible: very Steps to Reproduce: 1. disable print queue, say by power cycling the printer during comminucation 2. re-anable the queue after cups disables it Actual results: Job stays on queue Expected results: Job get printed. I've attached the cups error log in debug mode from such an occurrence. Job frost-8526 is now stuck on the queue.
Created attachment 137554 [details] cups error_log
The backend crashed while the job was printing, and so the printer was disabled and the job was stopped. In order to print the job again the printer must be re-enabled and the job restarted. This can be done using the web interface at http://localhost:631/. The real problem is that the backend crashed in the first place. Do you know what caused that, and can you cause it to happen again? If so it's something that would be great to fix.
Okay, this is new behavior then. Before when I restarted the queue, the job was restarted automatically. I can see the benefits of the new behavior (since the job that caused the problem will likely do it again), but it was unexpected. What's the command line tool to restart the job? As for the crash is the first place, usually it has because of bug #189931 which hangs the printer and requires a power cycle which then kills the print job and disables the queue. Not sure that was the case here though because I was able to print the restarted job.
Something like 'lp -i ID -H restart' I suppose.