[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#879491: marked as done (cups: printing 3 copies of every page)



Your message dated Thu, 26 Oct 2017 12:35:34 +0100
with message-id <26102017121954.ac789b1762bb@desktop.copernicus.org.uk>
and subject line Re: Bug#879491: cups: printing 3 copies of every page
has caused the Debian Bug report #879491,
regarding cups: printing 3 copies of every page
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner@bugs.debian.org
immediately.)


-- 
879491: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=879491
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems
--- Begin Message ---
Package: cups
Version: 2.2.5-2
Severity: important

(I'm labelling this as "important" because it's wasting large amounts
of paper.)

This is a weird bug, and I have little idea how to track down the
cause.

About a week or so ago, on my Debian testing system, printing commands
started producing three copies of every page on my local printer (so a
2-page document would come out at 3 copies of page 1 followed by 3
copies of page 2).  This is the case in at least all of the following
circumstances:

* Connect the printer with a USB cable, print via usb://...
* Connect the printer with via ethernet, print via dnssd://...
* Print from evince
* Print using lpr (eg: echo hello | lpr)
* Going to http://localhost:603/ and doing Maintenance -> Print Test Page

However, going to http://localhost:603/ and doing Maintenance -> Print
SELF Test Page only produces a single page of output!

I have updated cups to the latest version today (2.2.5-2), and that
has made no difference, and nor has deleting the printer from CUPS and
reinstalling it.  The PPD files have not changed in about a year
(except for the uninstalling and reinstalling, and even that installed
an identical copy to the existing PPD file).

So I'm at a bit of a loss as to the cause of this.  I also don't see
anything obvious in the log files, but I may be missing something.

Any suggestions?

Thanks!

   Julian

-- System Information:
Debian Release: buster/sid
  APT prefers stretch
  APT policy: (500, 'stretch'), (500, 'testing'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.13.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8) (ignored: LC_ALL set to en_GB.UTF-8), LANGUAGE=en_GB.utf8 (charmap=UTF-8) (ignored: LC_ALL set to en_GB.UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages cups depends on:
ii  cups-client            2.2.5-2
ii  cups-common            2.2.5-2
ii  cups-core-drivers      2.2.5-2
ii  cups-daemon            2.2.5-2
ii  cups-filters           1.17.9-1
ii  cups-ppdc              2.2.5-2
ii  cups-server-common     2.2.5-2
ii  debconf [debconf-2.0]  1.5.64
ii  ghostscript            9.22~dfsg-1
ii  libavahi-client3       0.7-3
ii  libavahi-common3       0.7-3
ii  libc-bin               2.24-17
ii  libc6                  2.24-17
ii  libcups2               2.2.5-2
ii  libcupscgi1            2.2.5-2
ii  libcupsimage2          2.2.5-2
ii  libcupsmime1           2.2.5-2
ii  libcupsppdc1           2.2.5-2
ii  libgcc1                1:7.2.0-11
ii  libstdc++6             7.2.0-11
ii  libusb-1.0-0           2:1.0.21-2
ii  poppler-utils          0.57.0-2
ii  procps                 2:3.3.12-3

Versions of packages cups recommends:
ii  avahi-daemon                     0.7-3
ii  colord                           1.3.3-2
ii  cups-filters [ghostscript-cups]  1.17.9-1
ii  printer-driver-gutenprint        5.2.13-1

Versions of packages cups suggests:
ii  cups-bsd                                   2.2.5-2
pn  cups-pdf                                   <none>
ii  foomatic-db-compressed-ppds [foomatic-db]  20171012-1
pn  hplip                                      <none>
ii  printer-driver-hpcups                      3.17.9+repack0-1
ii  smbclient                                  2:4.6.7+dfsg-2
ii  udev                                       235-2

-- debconf information:
  cupsys/raw-print: true
  cupsys/backend: lpd, socket, usb, snmp, dnssd

--- End Message ---
--- Begin Message ---
On Wed 25 Oct 2017 at 22:35:20 +0100, Julian Gilbey wrote:

> On Wed, Oct 25, 2017 at 08:08:04PM +0100, Brian Potkin wrote:

[Snip]

> > Can this changed be pinned down to any particular version of cups or
> > cups-filters? Or something you altered in cupsd.conf (for example) at
> > that time?
> 
> The upgrades I've done in October were as follows:
> 
> Oct 8:
> [UPGRADE] cups-browsed:amd64 1.16.4-1+b2 -> 1.17.8-1
> [UPGRADE] cups-filters:amd64 1.16.4-1+b2 -> 1.17.8-1
> [UPGRADE] cups-filters-core-drivers:amd64 1.16.4-1+b2 -> 1.17.8-1
> [UPGRADE] libcupsfilters-dev:amd64 1.16.4-1+b2 -> 1.17.8-1
> [UPGRADE] libcupsfilters1:amd64 1.16.4-1+b2 -> 1.17.8-1
> [UPGRADE] libfontembed1:amd64 1.16.4-1+b2 -> 1.17.8-1
> 
> Oct 11:
> [UPGRADE] cups-browsed:amd64 1.17.8-1 -> 1.17.9-1
> [UPGRADE] cups-filters:amd64 1.17.8-1 -> 1.17.9-1
> etc. (same packages as above)
> 
> Oct 22:
> [UPGRADE] cups:amd64 2.2.4-7 -> 2.2.5-2
> [UPGRADE] cups-bsd:amd64 2.2.4-7 -> 2.2.5-2
> etc., but the problem was already present before this date.
> 
> So perhaps it was the Oct 8 or Oct 11 upgrade of cups-filters?
> 
> I downgraded back to 1.16.4-1+b2, and then it worked fine.  I
> upgraded to 1.17.9-1 (dist-upgrade through aptitude) and immediately
> downgraded to 1.17.8-1, and it still worked, and then I upgraded back
> to 1.17.9-1, and it still works.
> 
> So now everything is working again, and I have no obvious way now of
> reproducing the problem.
> 
> How weird.

Thanks for doing this. It is always nice to have just a glimmer of a
cause or reason but sometimes "working" is sufficient.

> > A self-test page is actually produced by the printer itself; it is often
> > done from a button on the printer. The filtering system is not involved.
> 
> Ah, OK.
> 
> > Did you really use port 603 to bring up the CUPS web interface?
> 
> Duh, no, 631, sorry.
> 
> > You also mention Windows and Mac machines. I am not familiar with
> > printing from either of these, but my understanding is that Windows does
> > all the processing and sends the completed job to a CUPS server, which
> > does no processing. That is, the filtering system is bypassed. I wonder
> > whether your Mac is doing this too.
> 
> Yes, I should have been more precise: they print directly to the
> printer over ethernet, not via CUPS.  This showed me that the problem
> lay in the CUPS system, not in the printer itself.
> 
> > > [...]
> > > Any suggestions?
> > 
> > We'll need the printer model, the PPD used and an error_log.
> 
> So in the meantime, for the sake of information, it's a Brother
> DCP-9020CDW.  But there's no point in sending logs, etc., because it's
> now working again....

For your own benefit you might want to have a copy of the error_log.
Just in case of any future problem and a comparison is needed. 

> So I guess either close this bug report or mark it as unreproducible?

There is really nothing to take action on, so I'll close it.

Cheers,

Brian.

--- End Message ---

Reply to: