From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9) Gecko/20020401 Description of problem: If I have a printer set up to print to a remote unix printer and I lpr a file (it doesn't seem to matter how big it is), the file is printed successfully. But after the print job is done, I see this: Printer: lp@amazonis (dest lp@utopia) Queue: no printable jobs in queue Server: no server active Status: job 'draco@amazonis+557' saved at 01:35:00.695 Rank Owner/ID Class Job Files Size Time done draco@amazonis+557 A 557 m2revise.ps 11520043 01:34:41 Printer: lp@utopia Queue: no printable jobs in queue Status: job 'cfA557amazonis' removed at 01:43:45.723 Version-Release number of selected component (if applicable): $ rpm -q LPRng LPRng-3.8.9-3 How reproducible: Always Steps to Reproduce: 1. print a file to a network printer 2. wait for it to finish 3. lpq Actual Results: dead entries in local spool Expected Results: no entries in local spool Additional info: I am able to lprm the local job, so it really is there. However, oddly, if I print another file without lprm'ing it, the first job doesn't get in the way of the second one being printed.
I'm pretty sure this is expected behaviour. See the CHANGES file at about release 3.8.2.
Ok, this explains why I had 1 done job. However, I now have 2 done jobs: Printer: lp@amazonis (dest lp@utopia) Queue: no printable jobs in queue Server: no server active Status: job 'draco@amazonis+5' saved at 01:44:26.742 Rank Owner/ID Class Job Files Size Time done draco@amazonis+557 A 557 m2revise.ps 11520043 01:34:41 done draco@amazonis+5 A 5 wind_dir 310 01:44:26 Printer: lp@utopia Queue: no printable jobs in queue Status: job 'cfA005amazonis' removed at 01:46:29.358 From what I've read in the CHANGES file, the default is 1, which can be overridden at build time or from the lpd.conf file: - /etc/lpd.conf doesn't modify the default value - the spec file for LPRng hasn't passed a --with_done_jobs=N to configure to change from the default of 1. The CHANGES file indicates that in 3.8.9, a bug was found where more done jobs would lie around than the configured max was. However, despite the fact that the jobs were long ago done, they're still there. The version in skipjack beta 2 is 3.8.9-3, so presumably the bug they found has been fixed already. I have 2 done jobs, nevertheless. Ergo, there is still a bug here. If I'm wrong, please explain.
Yes, I understand the nature of the bug now. Thanks. *** This bug has been marked as a duplicate of 65094 ***