Printing multiple copies on remote printers

[Helge Blischke]

That, indeed, looks strange. I've no idea.

Helge

Anonymous wrote:
> 
> This is the error/problems that we are seeing:
> 
> lp -dmf1_shp_bro1 /fsprd/sqrout/output/fasap710_3223573.lis
> request id is mf1_shp_bro1-100763 (1 file(s))
> request id is mf1_shp_bro1-100764 (1 file(s))
> 
> I should only see 1 job id generated.  I assume that this is incorrect behavior.
> 
> > I think there is an issue with the handling of the copies attribute in
> > general.
> > The pstops filter sets the /NumCopies value in the page device
> > dictionary
> > (for language level >= 2; the /#copies value otherwise), but some
> > backends
> > on the other hand set the copies attribute in addition, e.g. the IPP and
> > the LPD
> > backend.
> > As the IPP RFCs don't specify which specification takes precedence, it
> > is implementation
> > dependent what really happens.
> >
> > Helge
> >
> >
> > Anonymous wrote:
> > >
> > > I am seeing similiar issues with local queues.  It appears that the jobs get queued multiple time.  It is generating multiple job ids for only 1 requests.  I end up getting anywhere from 2 to 10 copies of the same request.  I am seeing this both on Solaris 9 with cups 1.1.19 and the RHEL 3.0 version 1.1.17-13.3.22.
> > >
> > > Is anyone else seeing this?
> > > Is it a problem with cupsd or lp or both?
> > > What information do you want to help debug this?
> > >
> > > > russell-cups at stuart.id.au wrote:
> > > > > This bug has been observed in cups-1.1.20final+rc1 that
> > > > > comes with Debian, and cups-1.1.22 compiled from source.
> > > > >
> > > > > Remote printers are occassionally printing multiple
> > > > > copies of jobs.  None of the jobs had the "copies"
> > > > > option set.
> > > > >
> > > > > The multiple copies was caused by two things:
> > > > >
> > > > > 1.  Made http_wait() did not handle EINTR.
> > > >
> > > > This is an issue, but your fix is not the correct implementation
> > > > since it only handles a single interruption.
> > > >
> > > > > 2.  The wait in ipp_http_read was too short for connections
> > > > >     that run over the internet.
> > > >
> > > > Setting a 2 minute wait here is not appropriate; http_wait() is
> > > > only used when reading fragments in non-blocking mode, and only
> > > > the scheduler uses this mode.  Putting a 2-minute wait in the
> > > > scheduler opens CUPS up to additional DoS attacks but will not
> > > > resolve the problems you are seeing.
> > > >
> > > > > Note:
> > > > >     While both these bugs need to be fixed, neither completely
> > > > >     solves the original multiple copies problem.  To solve
> > > > >     that no data should be printed if there was a read or
> > > > >     other error.
> > > >
> > > > The usual response to HTTP or IPP errors in the initial query
> > > > phase of the backend's job submission is to retry the request or
> > > > connection.
> > > >
> > > > As we have never seen this particular problem before, I would
> > > > appreciate tcpdump/ethereal packet dumps of the traffic between
> > > > client and server so that we can determine at what point the
> > > > transaction is failing.
> > > >
> > > > Thanks!
> > > >
> > > > PS - you can post this problem and the dump files using the STR
> > > > form at:
> > > >
> > > >      http://www.cups.org/str.php
> > > >
> >
> > --
> > Helge Blischke
> > Softwareentwicklung
> > SRZ Berlin | Firmengruppe besscom
> > http://www.srz.de

-- 
Helge Blischke
Softwareentwicklung
SRZ Berlin | Firmengruppe besscom
http://www.srz.de