Bug#822263: cups printing from 2 recently patched systems stops with incomplete spooling; printer works fine with Windows
On Mon 25 Apr 2016 at 06:36:00 -0700, Dave Martin wrote:
> Sorry for the delay in getting back to you. Here's a detail of my
> setup:Printer model: Hewlett-Packard 952c
>
> The queue name is: HPDJ952c
> I'm using CUPS+Gutenprint v5.2.10 (color, 2-sided printing)
> The print server is a Hawking Technology HPS1U
> I use IPP (using ipp, not http) printing, with the URI:
> *lpd://192.168.1.250/lpt1*
>
> There is a 2nd queue, HPDJ952c-2, which is using IPP14
> It experiences the same problem.
>
> I have both queues configured for grayscale printing.
You are using the LPD protocol to send a job to the print server, not
IPP.
> This morning, I started with a fresh system boot, and attempted a print job.
> The print job was a CUPS "Print test page" from the CUPS web interface. As
> usual, activity on the printer started within a few seconds. Unfortunately,
> as has been happening for the past several weeks, printing hung - this time
> with the spool reporting 0% complete. As I've been composing this email,
> I'm noticing that every few minutes, the printer will print a a little bit
> more, but I still have only about 1-inch worth of the expected output on the
> paper and it has now been more than 30 minutes.
Does this affect text and PDF file too?
> lpstat -t
> After trying the CUPS test print, the results of lpstat -t at 06:00:15 AM
> PDT are:
>
> scheduler is running
> system default destination: HPDJ952c
> device for HPDJ952c: lpd://192.168.1.250/lpt1
> device for HPDJ952c-2: lpd://192.168.1.250/lpt1
> HPDJ952c accepting requests since Mon 25 Apr 2016 05:48:02 AM PDT
> HPDJ952c-2 accepting requests since Fri 22 Apr 2016 12:54:03 PM PDT
> printer HPDJ952c now printing HPDJ952c-26. enabled since Mon 25 Apr
> 2016 05:48:02 AM PDT
> Spooling job, 0% complete.
> printer HPDJ952c-2 is idle. enabled since Fri 22 Apr 2016 12:54:03
> PM PDT
> HPDJ952c-26 anonymous 1024 Mon 25 Apr 2016
> 05:48:02 AM PDT
>
> You mentioned in your email that you'd like a log, and that the wiki would
> help me with that. I don't know which wiki to look at, so I've attached 2
> text files. Both files cover the time span several minutes before the print
> attempt, to several minutes after:
>
> Bug822263-20160425-01.txt - is the output of "tail -n 100 -f
> /var/log/cups/error_log"
> Bug822263-20160425-01.txt - is from the CUPS web interface "View Error Log"
I had the Debian wiki in mind; However, you have sent the requested
logs. Thanks.
The filters started are
bannertopdf (PID 3208)
pdftopdf (PID 3209)
gstoraster (PID 3210)
rastertogutenprint.5.2 (PID 3211)
lpd (PID 3212)
The first four exit with no error, so the filtering chain produces a
file ready to be sent to the printer. The fifth filter transports the
printer-ready file to the server but the log shows what you have
observed - it does not complete and exit. The problem appears to lie
with the interaction between the backend filter and the server.
So why should one Wheezy machine print successfully and the other not?
They use the same backend. 'lpstat -t' is the same for both? Also, any
update to the Jessie machine leaves the lpd backend unchanged so it is
unclear to me how it could affect printing. I'm having a hard time
seeing where the bug in CUPS is.
> I have attempted to use the hpijs driver instead of Gutenprint, but I either
> get the same results, or a message being printed '...If you can read this,
> you're using the wrong driver...'
>
> Let me know if you need further information.
It seems your server also supports the IPP and RAW (JetDirect)
protocols. You could set up queues on the Jessie machine with
lpadmin -p test-1 -v ipp://192.168.1.250:631/lpt1 -E -m gutenprint.5.2://hp-dj_952c/expert
and
lpadmin -p test-2 -v socket://192.168.1.250:9100 -E -m gutenprint.5.2://hp-dj_952c/expert
Do they work?
Regards,
Brian.
(Nothing to do with the report itself but Dave's mail did not appear in
debian-printing. Is this some vagary in list behaviour?)
Reply to: