Bug#817246: gziptoany fails with signal 13 since upgrade to jessie
On Wed 09 Mar 2016 at 13:02:36 +0100, martin f krafft wrote:
> Since the upgrade to jessie, we cannot print any longer. Here is the
> relevant debug log:
>From the server?
> Started filter /usr/lib/cups/filter/gziptoany (PID 7212)
> Started filter /usr/lib/cups/filter/hpcups (PID 7213)
> Started backend /usr/lib/cups/backend/hp (PID 7214)
> prnt/hpcups/HPCupsFilter.cpp 530: cupsRasterOpen failed, fd = 0
Yhis is the first message. I would read this as a failure in hpcups/hp.
> PID 7212 (/usr/lib/cups/filter/gziptoany) did not catch or ignore signal 13.
Signal 13 (please see signal(7)) is SIGPIPE. It looks like gziptoany
tried to write some output to hpcups and it wasn't having anything to do
with it. This line could be a reaction to the previous one.
> PID 7213 (/usr/lib/cups/filter/hpcups) stopped with status 1.
So hpcups stopped because it didn't like what it saw. Now, could the
issue be with hpcups and not gziptoany.
> Hint: Try setting the LogLevel to "debug" to find out more.
> prnt/backend/hp.c 902: ERROR: null print job total=0
> PID 7214 (/usr/lib/cups/backend/hp) exited with no errors.
> End of messages
> printer-state=3(idle)
> printer-state-message="Filter failed"
> printer-state-reasons=none
>
> as you can see, gziptoany failed without any additional information
> that could be useful (the LogLevel hint does not help when debug
> level is already selected).
I'm unsure about gziptoany failing being the basic cause.
> This is reproducible with various different PDF files and only
> occurs when printing happens via the network (using ipps://…). The
> printer is advertised using the (old) cups broadcast, using
> cups-browsed on both server and client. Printing locally on the
> print server works fine.
This sounds as though the problem should be reproducible here. Please
post full debug logs for client and server for a failed job. The printer
and PPD would also be useful to know.
Reply to: