Bug 208899 - With 1.2.4, re-enabling printer does not restart stopped jobs
Summary: With 1.2.4, re-enabling printer does not restart stopped jobs
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Fedora
Classification: Fedora
Component: cups
Version: 5
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Tim Waugh
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2006-10-02 15:36 UTC by Orion Poplawski
Modified: 2007-11-30 22:11 UTC (History)
0 users

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2006-10-03 15:26:21 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
cups error_log (279.62 KB, text/plain)
2006-10-02 15:36 UTC, Orion Poplawski
no flags Details

Description Orion Poplawski 2006-10-02 15:36:07 UTC
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.

Comment 1 Orion Poplawski 2006-10-02 15:36:08 UTC
Created attachment 137554 [details]
cups error_log

Comment 2 Tim Waugh 2006-10-03 13:05:16 UTC
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.

Comment 3 Orion Poplawski 2006-10-03 15:26:21 UTC
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.

Comment 4 Tim Waugh 2006-10-03 15:29:22 UTC
Something like 'lp -i ID -H restart' I suppose.


Note You need to log in before you can comment on or make changes to this bug.