Printing multiple copies on remote printers

[Anonymous]

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