Bug 12797

Summary: lpr stalls most days, dead(?) job fronts queue
Product: [Retired] Red Hat Linux Reporter: Martin Whinnery <martin>
Component: lprAssignee: Bernhard Rosenkraenzer <bero>
Status: CLOSED ERRATA QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: 6.1   
Target Milestone: ---   
Target Release: ---   
Hardware: i386   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2000-06-21 23:55:27 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

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.