Bug 15651 - No error handling for non-existing queues.
No error handling for non-existing queues.
Status: CLOSED WONTFIX
Product: Red Hat Linux
Classification: Retired
Component: LPRng (Show other bugs)
7.0
i386 Linux
high Severity medium
: ---
: ---
Assigned To: Crutcher Dunnavant
Winston gold
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2000-08-07 12:01 EDT by Trond Eivind Glomsrxd
Modified: 2008-05-01 11:37 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2000-08-11 15:59:13 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Trond Eivind Glomsrxd 2000-08-07 12:01:43 EDT
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 11:13:39 EDT
This defect is considered MUST-FIX for Winston Gold-release
Comment 2 Crutcher Dunnavant 2000-08-08 16:04:58 EDT
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 16:12:38 EDT
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 16:37:12 EDT
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
request
to the author. Just because you want it to do something does not mean there is a
bug
if it was not designed to do it.
Comment 5 Trond Eivind Glomsrxd 2000-08-08 16:42:09 EDT
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
functionality".

Back to the main topic:  Yes, I think it should do a new call if necessary.
Comment 6 Crutcher Dunnavant 2000-08-08 16:55:49 EDT
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-
       tions.

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

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
users.

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 16:59:48 EDT
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 15:59:11 EDT
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.