Bug 12797 - lpr stalls most days, dead(?) job fronts queue
Summary: lpr stalls most days, dead(?) job fronts queue
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: lpr
Version: 6.1
Hardware: i386
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Bernhard Rosenkraenzer
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2000-06-21 23:55 UTC by Martin Whinnery
Modified: 2008-05-01 15:37 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2000-06-21 23:55:27 UTC
Embargoed:


Attachments (Terms of Use)

Description Martin Whinnery 2000-06-21 23:55:26 UTC
We are running a RHL 6.1 box as a Samba server. We print from up to 30 W95
boxes, using Adobe's latest PS driver, and strip DSC comments fro the
resulting job before sending through gs and spooling via lpr.
Every now and again, the queue stalls, and lpq behaves strangely, giving
the following output:

Rank   Owner      Job  Files                                 Total Size
0 bytes
1st    aluser     107  blah.filename                         83 bytes
2nd    aluser     108  blah.filename                         16769 bytes
3rd    aluser     109  blah.filename                         15243 bytes
4th    aluser     110  blah.filename                         40880 bytes

and won't return without ^C

I've a feeling that the relevant line here is '0 bytes', and when I check
the relevant spool directory, there is a zero length control file
(cfblahblah) owned by root.

Any thoughts?

PS I'm not at work, so the more perceptive reader will realise that the
output listed above ain't quite right. But the '0 bytes' biit sure is.

Comment 1 Bernhard Rosenkraenzer 2000-06-23 11:25:06 UTC
This should be fixed in the current errata lpr package.
If that doesn't work for you either, try the LPRng package from rawhide.


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