Bug 15651 - No error handling for non-existing queues.
Summary: No error handling for non-existing queues.
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: LPRng
Version: 7.0
Hardware: i386
OS: Linux
Target Milestone: ---
Assignee: Crutcher Dunnavant
QA Contact:
Whiteboard: Winston gold
Depends On:
TreeView+ depends on / blocked
Reported: 2000-08-07 16:01 UTC by Trond Eivind Glomsrxd
Modified: 2008-05-01 15:37 UTC (History)
0 users

Clone Of:
Last Closed: 2000-08-11 19:59:13 UTC

Attachments (Terms of Use)

Description Trond Eivind Glomsrxd 2000-08-07 16:01:43 UTC
lprm doesn't handle non-existing queues properly - it doesn't report that
no such queue exists, and it doesn't set a non-0 return value.

Comment 1 Glen Foster 2000-08-08 15:13:39 UTC
This defect is considered MUST-FIX for Winston Gold-release

Comment 2 Crutcher Dunnavant 2000-08-08 20:04:58 UTC
This functionality would be VERY non-trivial to add, as the lprm output is
actually coming from lpd, so we would need a parser to parse a status request
before we made the removal request, which would significantly complicate the
workings of lprm.

Adding this functionality without changing any other behaviour would be a very
risky proposition.
I am going to send a feature request to the LPRng upstream, and closing this as
a wontfix.

Comment 3 Trond Eivind Glomsrxd 2000-08-08 20:12:38 UTC
Fixing a bug is an enhancement, and this is a bug - not an RFE.

Besides, adding checks for queues either in the daemon or lprm itself is a
little work, but very far from risky.

Comment 4 Crutcher Dunnavant 2000-08-08 20:37:12 UTC
The spooler checks for spools, of course, it just doesn't tell
the client if it didn't find any, and changing the communtication
nature of lpd is the wrong thing.

The only Right Thing is to make a status request on the spooler,
parse the text block it returns, and figure out if it has that spool,
then make the remove call if it does, and drop an error if it doesn't.

This is not a trival problem, the complexity of lprm goes up by a second
network call and a parser, and adding this without breaking anything else is
not simple.

This IS an enhancement. There is no documented behaviour that says there will
be an error message, and it did not do it before. I've sent an enhancement
to the author. Just because you want it to do something does not mean there is a
if it was not designed to do it.

Comment 5 Trond Eivind Glomsrxd 2000-08-08 20:42:09 UTC
It's clearly a bug not to report that a queue is non-existing - I don't see any
point arguing that. Saying otherwise would imply that e.g. gcc could quietly do
nothing if asked to operate upon a non-existing file... and that fixing that
would be an enhancement, not a fix. "Enhancement" in bugzilla means "new

Back to the main topic:  Yes, I think it should do a new call if necessary.

Comment 6 Crutcher Dunnavant 2000-08-08 20:55:49 UTC
It is not 'clearly' a bug.

the lprm behaviour is documented as:
       Lprm  will announce the names of any files it removes and is silent if
there are no
       jobs in the queue which match the request  list.   If  the  job  being 
removed  is
       active,  the LPD server will stop printing the job and then restart
printing opera-

So this is a special case (there are never any jobs waiting in a non-existant

Now admittedly, there are some lprm programs which behave differently, But that
is not the point. 

The point is that this would significantly change the internal behaviour of the
lprm that we ship, and could quite easily generate a bit of surprise on the user
end. The lack of response if a spool does not exist is not surprising to LPRng

But if we put a parser into the lpr code, we have to change it every time the
lpd output format changes, and parsers are not simple code, it would be a
relatively large patch for a piece of funcionality that A) is not internaly
developed, and B) works now.

I have sent a feature request to the author, well see what he says about adding
it, but adding a parser at the moment is much more likely to increase bugs than
to close this minor issue.

So I am NOT adding a parser because a trivial error issue does not warrant that
kind of rewrite for a piece of external code.

Comment 7 Trond Eivind Glomsrxd 2000-08-08 20:59:48 UTC
You don't need a fullblown parser at all, but if you want to close it as
"WONTFIX" feel free.

Some bugs go that way.

Comment 8 Hans de Goede 2000-08-11 19:59:11 UTC
Ok I'm checking my depends packages, and the conces seems to be wontfix so I'm
closing this reopen if I've closed it wrongly.

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