Bug 164472 - Odd queue recreation behaviour - lost jobs
Summary: Odd queue recreation behaviour - lost jobs
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: cups
Version: 3.0
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Tim Waugh
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2005-07-28 03:40 UTC by Norm Murray
Modified: 2007-11-30 22:07 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2007-10-19 18:56:51 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)

Description Norm Murray 2005-07-28 03:40:08 UTC
cups-1.1.17-13.3.27

Testing against a reported crash of cupsd, I ran into this interesting behaviour:

1 - create a queue on a remote CUPS server, shared
2 - print on a CUPS client system to the browsed queue, faster than the remote
can accept jobs - need to have locally queued jobs for this
3 - stop CUPS on the remote server
4 - wait for the browse timeout to pass so the queue gets deleted on the client

Here's where things get amusing:
lpstat -t will show:
printer droid now printing droid-0.  enabled since Jan 01 00:00
printer file is idle.  enabled since Jan 01 00:00
printer gryffindor is idle.  enabled since Jan 01 00:00
printer hacked0 is idle.  enabled since Jan 01 00:00
printer hacked1 is idle.  enabled since Jan 01 00:00
printer hacked2 is idle.  enabled since Jan 01 00:00
printer hacked3 is idle.  enabled since Jan 01 00:00
printer hacked4 is idle.  enabled since Jan 01 00:00
printer hacked5 is idle.  enabled since Jan 01 00:00
printer hacked9 is idle.  enabled since Jan 01 00:00
printer minolta now printing minolta-0.  enabled since Jan 01 00:00
printer null is idle.  enabled since Jan 01 00:00
printer raven now printing raven-0.  enabled since Jan 01 00:00
norm-testing2-32        root          500000768   Thu 28 Jul 2005 12:51:26 PM EST
norm-testing2-33        root          500000768   Thu 28 Jul 2005 12:51:48 PM EST
norm-testing2-34        root          500000768   Thu 28 Jul 2005 12:52:05 PM EST
norm-testing2-35        root          500000768   Thu 28 Jul 2005 12:52:26 PM EST
norm-testing2-36        root          500000768   Thu 28 Jul 2005 12:52:44 PM EST
norm-testing2-37        root          500000768   Thu 28 Jul 2005 12:52:59 PM EST
norm-testing2-38        root          500000768   Thu 28 Jul 2005 12:53:22 PM EST
norm-testing2-39        root          500000768   Thu 28 Jul 2005 12:53:41 PM EST
norm-testing2-40        root          500000768   Thu 28 Jul 2005 12:53:59 PM EST
norm-testing2-41        root          500000768   Thu 28 Jul 2005 12:54:21 PM EST
norm-testing2-42        root          500000768   Thu 28 Jul 2005 12:54:43 PM EST
norm-testing2-43        root          500000768   Thu 28 Jul 2005 12:55:05 PM EST
norm-testing2-44        root          500000768   Thu 28 Jul 2005 12:55:22 PM EST
norm-testing2-45        root          500000768   Thu 28 Jul 2005 12:55:40 PM EST
norm-testing2-46        root          500000768   Thu 28 Jul 2005 12:56:06 PM EST
norm-testing2-47        root          500000768   Thu 28 Jul 2005 12:56:26 PM EST
norm-testing2-48        root          500000768   Thu 28 Jul 2005 12:56:41 PM EST
norm-testing2-49        root          500000768   Thu 28 Jul 2005 12:57:03 PM EST
norm-testing2-50        root          500000768   Thu 28 Jul 2005 12:57:24 PM EST
norm-testing2-51        root          500000768   Thu 28 Jul 2005 12:57:47 PM EST
norm-testing2-52        root          500000768   Thu 28 Jul 2005 12:58:07 PM EST
norm-testing2-53        root          500000768   Thu 28 Jul 2005 12:58:32 PM EST
norm-testing2-54        root          500000768   Thu 28 Jul 2005 12:58:54 PM EST
norm-testing2-55        root          500000768   Thu 28 Jul 2005 12:59:16 PM EST
norm-testing2-56        root          500000768   Thu 28 Jul 2005 12:59:35 PM EST


i.e. many jobs in in queue for a queue that does not exist. 

On the client, service cups restart
lpstat -t will now show this:
[root@amazon-6000 mm]# lpstat -t
scheduler is running
no system default destination
device for file: /tmp/printfile
device for hacked0: /dev/null
device for hacked1: /dev/null
device for hacked2: /dev/null
device for hacked3: /dev/null
device for hacked4: /dev/null
device for hacked5: /dev/null
device for hacked9: /dev/null
device for norm-testing2: ipp://amazon-6000:631/printers/norm-testing2
device for null: /tmp/barney
file accepting requests since Jan 01 00:00
hacked0 accepting requests since Jan 01 00:00
hacked1 accepting requests since Jan 01 00:00
hacked2 accepting requests since Jan 01 00:00
hacked3 accepting requests since Jan 01 00:00
hacked4 accepting requests since Jan 01 00:00
hacked5 accepting requests since Jan 01 00:00
hacked9 accepting requests since Jan 01 00:00
norm-testing2 not accepting requests since Jan 01 00:00 -
 
null accepting requests since Jan 01 00:00
printer file is idle.  enabled since Jan 01 00:00
printer hacked0 is idle.  enabled since Jan 01 00:00
printer hacked1 is idle.  enabled since Jan 01 00:00
printer hacked2 is idle.  enabled since Jan 01 00:00
printer hacked3 is idle.  enabled since Jan 01 00:00
printer hacked4 is idle.  enabled since Jan 01 00:00
printer hacked5 is idle.  enabled since Jan 01 00:00
printer hacked9 is idle.  enabled since Jan 01 00:00
printer norm-testing2 disabled since Jan 01 00:00 -
 
printer null is idle.  enabled since Jan 01 00:00



The queue has been recreated locally, with a loopback destination, but the jobs
are gone. 


localhost:631/printers shows the queue to have the following information:
norm-testing2  	Remote Printer on unknown  	
		Description: No Information Available
                Location: Location Unknown
                Printer State: stopped, rejecting jobs.

So, there is now a locally defined queue, despite there never before having been
one, and all the jobs that had been queued to print are gone.

Comment 1 RHEL Program Management 2007-10-19 18:56:51 UTC
This bug is filed against RHEL 3, which is in maintenance phase.
During the maintenance phase, only security errata and select mission
critical bug fixes will be released for enterprise products. Since
this bug does not meet that criteria, it is now being closed.
 
For more information of the RHEL errata support policy, please visit:
http://www.redhat.com/security/updates/errata/
 
If you feel this bug is indeed mission critical, please contact your
support representative. You may be asked to provide detailed
information on how this bug is affecting you.


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