Bugzilla will be upgraded to version 5.0 on a still to be determined date in the near future. The original upgrade date has been delayed.
Bug 1010580 - Remote printing doesn't work - prnt/hpcups/HPCupsFilter.cpp 542: cupsRasterOpen failed, fd = 6
Remote printing doesn't work - prnt/hpcups/HPCupsFilter.cpp 542: cupsRasterOp...
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: cups (Show other bugs)
19
All Linux
medium Severity unspecified
: ---
: ---
Assigned To: Tim Waugh
Fedora Extras Quality Assurance
: Reopened
: 1012299 1018030 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-09-21 14:04 EDT by Damian Wrobel
Modified: 2018-06-03 08:59 EDT (History)
10 users (show)

See Also:
Fixed In Version: cups-1.6.4-2.fc19
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 1013040 (view as bug list)
Environment:
Last Closed: 2013-10-14 03:13:00 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
error_log (remote print test) (379.51 KB, text/plain)
2013-09-21 14:04 EDT, Damian Wrobel
no flags Details
error_log (local print test) (60.94 KB, text/plain)
2013-09-21 14:05 EDT, Damian Wrobel
no flags Details
content of the /etc/cups directory from the remote machine (42.03 KB, application/x-xz)
2013-09-24 15:26 EDT, Damian Wrobel
no flags Details

  None (edit)
Description Damian Wrobel 2013-09-21 14:04:53 EDT
Created attachment 800954 [details]
error_log (remote print test)

Description of problem:
Remote printing doesn't work while the local one works without any problems.

I have a desktop to which a printer is connected and two laptops in local network. This setup worked fine up to F18. Once upgraded on all machines to F19 I can't print from the laptops, while the local printing works fine.

Version-Release number of selected component (if applicable):
$ rpm -qa | grep -e cups -e hplip | grep -v debuginfo | sort
bluez-cups-4.101-9.fc19.i686
cups-1.6.3-4.fc19.i686
cups-devel-1.6.3-4.fc19.i686
cups-filesystem-1.6.3-4.fc19.noarch
cups-filters-1.0.38-2.fc19.i686
cups-filters-libs-1.0.38-2.fc19.i686
cups-libs-1.6.3-4.fc19.i686
cups-pdf-2.6.1-6.fc19.i686
cups-pk-helper-0.2.4-2.fc19.i686
ghostscript-cups-9.07-12.fc19.i686
gutenprint-cups-5.2.9-11.fc19.i686
hplip-3.13.9-2.fc19.i686
hplip-common-3.13.9-2.fc19.i686
hplip-gui-3.13.9-2.fc19.i686
hplip-libs-3.13.9-2.fc19.i686
libgnomecups-0.2.3-12.fc18.i686
python-cups-1.9.63-4.fc19.i686

How reproducible:
100$

Steps to Reproduce:
1. $echo test | lpr # on local machine
2. $echo test | lpr # from remote machine

Actual results:
Local printing works, while remote doesn't work.

Expected results:
Both local and remote printing should works.

Additional info:
Not sure if this could case the problem but while attempting to print from the remote machine in the error_log there are the following suspicious lines:

[Job 2436] prnt/hpcups/HPCupsFilter.cpp 542: cupsRasterOpen failed, fd = 6
select_timeout: JobHistoryUpdate=1379870824
prnt/backend/hp.c 833: ERROR: null print job total=0
Comment 1 Damian Wrobel 2013-09-21 14:05:42 EDT
Created attachment 800955 [details]
error_log (local print test)
Comment 2 Jiri Popelka 2013-09-23 08:18:59 EDT
(In reply to Damian Wrobel from comment #0)
> Created attachment 800954 [details]
> error_log (remote print test)

And this one is from the remote machine or from machine connected to the printer ?
Comment 3 Damian Wrobel 2013-09-23 11:24:40 EDT
(In reply to Jiri Popelka from comment #2)
> And this one is from the remote machine or from machine connected to the
> printer ?
Both are from the machine the printer is connected to. LogLevel was set to debug2.
Comment 4 Tim Waugh 2013-09-24 07:44:21 EDT
192.168.160.9 is sending invalid application/vnd.cups-raster data.

How is that client configured? It seems to be running filters locally before sending the job to the CUPS server, but that's not the best way to do things and seems to be causing a problem here.

Rather than setting a driver for the remote printer, it should just send the data it gets from the application... in other words, it should be a 'raw' queue.
Comment 5 Damian Wrobel 2013-09-24 15:25:14 EDT
(In reply to Tim Waugh from comment #4)
> How is that client configured?

It was just automatically detected by the KDE printer manager (/usr/bin/kcmshell4 kcm_printer_manager). I've just selected the PPD and as aforementioned it worked fine up to the F18. On F19 I've even deleted and added again the printer but it didn't help.
Comment 6 Damian Wrobel 2013-09-24 15:26:24 EDT
Created attachment 802437 [details]
content of the /etc/cups directory from the remote machine
Comment 7 Damian Wrobel 2013-09-24 15:34:43 EDT
(In reply to Tim Waugh from comment #4)
> 192.168.160.9 is sending invalid application/vnd.cups-raster data.

I see that the /etc/cups/ppd/HP_DeskJet_930C.ppd on the remote machine contains the following line: 

*cupsFilter:    "application/vnd.cups-raster 100 rastertogutenprint.5.2"

Does that mean that this might cause the problem? But I didn't modify this file.
Comment 8 Damian Wrobel 2013-09-24 16:19:38 EDT
I've just commented out the cupsFilter line and the printing started to work.

Thank you very much for the hint you've provided.

Does that mean that I choose the wrong driver or it's a problem in the driver  (PPD file) itself?
Comment 9 Tim Waugh 2013-09-25 06:07:38 EDT
It shouldn't have a driver at all. It needs to be a raw queue.

Try adjusting the queue like this:

lpadmin -p HP-deskJet_930C -m raw

Does that work?
Comment 10 Damian Wrobel 2013-09-25 14:11:24 EDT
(In reply to Tim Waugh from comment #9)
> Does that work?
Yes, that also works.
Comment 11 Jiri Popelka 2013-09-27 05:57:00 EDT
*** Bug 1012299 has been marked as a duplicate of this bug. ***
Comment 12 Tim Waugh 2013-09-27 06:12:39 EDT
Hmm, there seem to have been several bugs like this, and really there's no reason it shouldn't work to have the filters run on the client.

Now that I look more closely at it I think I can see what's wrong: the filters converted the data (via application/vnd.cups-raster) to the printer's native command set (whatever that might be)... but when the job got sent to the CUPS server it was tagged as application/vnd.cups-raster rather than, say, application/octet-stream.

I wonder how long that's been broken.
Comment 13 Jaco 2013-09-27 07:03:45 EDT
Hi Tim
From my research to try to sort it out, it appears that it started to become a problem from CUPS 1.5.3 onwards.
Comment 14 Tim Waugh 2013-09-27 10:06:34 EDT
OK, I can reproduce it here with cups-1.6.3-4.fc19.x86_64.
Comment 15 Tim Waugh 2013-09-27 12:02:53 EDT
This looks like the culprit:

commit 44b1294cd4ab7940a5f79ca8022bf7a93b8e7486
Author: mike <mike@7a7537e8-13f0-0310-91df-b6672ffda945>
Date:   Tue Mar 19 18:35:14 2013 +0000

    Need to ignore trailing printer/foo null filter...
    
    
    git-svn-id: http://svn.easysw.com/public/cups/trunk@10918 7a7537e8-13f0-0310

diff --git a/scheduler/job.c b/scheduler/job.c
index cce4b39..aed35e2 100644
--- a/scheduler/job.c
+++ b/scheduler/job.c
@@ -635,10 +635,31 @@ cupsdContinueJob(cupsd_job_t *job)        /* I - Job */
       goto abort_job;
     }
 
-    /* SET FINAL_CONTENT_TYPE HERE */
+   /*
+    * Figure out the final content type...
+    */
+
+    cupsdLogJob(job, CUPSD_LOG_DEBUG, "%d filters for job:",
+                cupsArrayCount(filters));
+    for (filter = (mime_filter_t *)cupsArrayFirst(filters);
+         filter;
+         filter = (mime_filter_t *)cupsArrayNext(filters))
+      cupsdLogJob(job, CUPSD_LOG_DEBUG, "%s (%s/%s to %s/%s, cost %d)",
+                 filter->filter,
+                 filter->src ? filter->src->super : "???",
+                 filter->src ? filter->src->type : "???",
+                 filter->dst ? filter->dst->super : "???",
+                 filter->dst ? filter->dst->type : "???",
+                 filter->cost);
+
     if (!job->printer->remote)
     {
-      filter = (mime_filter_t *)cupsArrayLast(filters);
+      for (filter = (mime_filter_t *)cupsArrayLast(filters);
+           filter && filter->dst;
+           filter = (mime_filter_t *)cupsArrayPrev(filters))
+        if (strcmp(filter->dst->super, "printer") ||
+            strcmp(filter->dst->type, job->printer->name))
+          break;
 
       if (filter && filter->dst)
       {
Comment 16 Fedora Update System 2013-10-02 08:55:38 EDT
cups-1.7-0.26.rc1.fc20 has been submitted as an update for Fedora 20.
https://admin.fedoraproject.org/updates/cups-1.7-0.26.rc1.fc20
Comment 17 Fedora Update System 2013-10-02 21:15:59 EDT
Package cups-1.7-0.26.rc1.fc20:
* should fix your issue,
* was pushed to the Fedora 20 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing cups-1.7-0.26.rc1.fc20'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2013-18188/cups-1.7-0.26.rc1.fc20
then log in and leave karma (feedback).
Comment 18 Fedora Update System 2013-10-09 10:38:34 EDT
cups-1.7-0.26.rc1.fc20 has been pushed to the Fedora 20 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 19 Tim Waugh 2013-10-11 05:52:16 EDT
Re-opening for Fedora 19.
Comment 20 Tim Waugh 2013-10-11 05:52:46 EDT
*** Bug 1018030 has been marked as a duplicate of this bug. ***
Comment 21 Fedora Update System 2013-10-11 07:50:17 EDT
cups-1.6.4-2.fc19 has been submitted as an update for Fedora 19.
https://admin.fedoraproject.org/updates/cups-1.6.4-2.fc19
Comment 22 Fedora Update System 2013-10-11 19:59:10 EDT
Package cups-1.6.4-2.fc19:
* should fix your issue,
* was pushed to the Fedora 19 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing cups-1.6.4-2.fc19'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2013-18910/cups-1.6.4-2.fc19
then log in and leave karma (feedback).
Comment 23 David Jones 2013-10-12 00:54:25 EDT
I can confirm that 1.6.4 fixes the bug.

Client:
Fedora 19 x86_64
cups 1.6.4-2

Server:
Fedora 19 x86_64
cups 1.6.3-4
with USB printer Samsung SCX-4623f
Comment 24 Fedora Update System 2013-10-14 03:13:00 EDT
cups-1.6.4-2.fc19 has been pushed to the Fedora 19 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 25 Fedora Update System 2013-10-14 13:16:47 EDT
cups-1.6.4-2.fc19 has been pushed to the Fedora 19 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 26 Tim Waugh 2014-10-15 08:33:29 EDT
See bug #1149244. This patch is being reverted but I wasn't able to reproduce this bug after doing so.
Comment 27 Peter Lawler 2015-02-23 16:58:02 EST
I've been getting this between my F21 (client w/ cups-1.7.5-15 ) and RHEL6.6 (server w/ cups-1.4.2-67) machines using an HP F2480 deskjet printer.
Only way I've been able to work around is by following Comment #7 on the RHEL6.6 side. Following Comment #9 had no effect.
I realise this is closed, just wondering if something needs backporting or whether I'm doing something else terribly wrong.
Comment 28 Tim Waugh 2015-02-24 05:45:44 EST
Peter: what PPD is set for the local queue, and what PPD is set for the remote queue? i.e. what does 'sudo grep ^.NickName /etc/cups/ppd/myqueue.ppd' say, with the queue name substituted for myqueue, on each machine?
Comment 29 John Chivall 2015-02-28 06:07:13 EST
Hi,

I'm also hitting this bug. F21 client with cups 1.7.5-12, F20 server with cups 1.7.5-12.

Relevant lines in the cups error log:
D [28/Feb/2015:10:46:50 +0000] [Job 648] prnt/hpcups/HPCupsFilter.cpp 537: cupsRasterOpen failed, fd = 0
D [28/Feb/2015:10:46:50 +0000] [Job 648] PID 6638 (/usr/lib/cups/filter/hpcups) stopped with status 1.
D [28/Feb/2015:10:46:50 +0000] [Job 648] Hint: Try setting the LogLevel to "debug" to find out more.
D [28/Feb/2015:10:46:50 +0000] [Job 648] PID 6637 (/usr/lib/cups/filter/gziptoany) did not catch or ignore signal 13.
D [28/Feb/2015:10:46:50 +0000] [Job 648] prnt/backend/hp.c 896: ERROR: null print job total=0
D [28/Feb/2015:10:46:50 +0000] [Job 648] PID 6639 (/usr/lib/cups/backend/hp) exited with no errors.

Commenting out the *cupsFilter line in the ppd on the server fixes the issue, as per Comment #7.

Results of sudo grep ^.NickName /etc/cups/ppd/HP_Photosmart_C4400_series.ppd:

Client: *NickName: "HP Photosmart c4400 Series, hpcups 3.14.10"
Server: *NickName: "HP Photosmart c4400 Series, hpcups 3.14.10"

Cheers.
Comment 30 Alessandro Suardi 2015-02-28 09:49:03 EST
One more here:

 - F17 cups server working fine with F19 client
 --> upgrade F19 client to F21, printing ceases to work.

*cupsFilter commented in PPD on server, cups restart, printing works again.

*NickName: "HP Photosmart c4600 Series, hpcups 3.13.4"

cups is 1.7.5-13 on client, 1.5.4-22 on server.
Comment 31 Tim Waugh 2015-03-02 06:19:33 EST
Commenting out *cupsFilter is not correct and may lead to subtle bugs.

The correct solution is to do one of the following.

Either:

* Set the client queue as 'raw' so that all processing occurs at the server

Or:

* Set the server queue as 'raw' so that all processing occurs at the clients, and ensure that raw file printing is enabled in mime.types
Comment 32 Peter Lawler 2015-04-28 17:30:38 EDT
(In reply to Tim Waugh from comment #28)
> Peter: what PPD is set for the local queue, and what PPD is set for the
> remote queue? i.e. what does 'sudo grep ^.NickName
> /etc/cups/ppd/myqueue.ppd' say, with the queue name substituted for myqueue,
> on each machine?

Apologies for taking so long to reply:
Both client and server have
*NickName: "HP Deskjet f2400 Series, hpcups 3.12.4"

Might I make a suggestion that, at least in F21 Gnome (yeah I know it's about to be obsoleted) that the lack of printing should be trapped better and that there be some non-command line UI to be able to change the client queue. If this has been improved in later releases, feel free to ignore me.

(Yeah, I 'fixed' it by "sudo lpadmin -p HP-Deskjet-F2400 -m raw" but I'm not totally convinced this is a suitable solution for SoHo setups)
Comment 33 Alessandro Suardi 2015-05-03 17:02:07 EDT
Finally upgraded the print server to F21, went to redo the printer configuration even on client side (same F21 box as before) and sure enough this issue popped up again :)

As Peter, I went server-side and lpadmin'd -m raw the printer - first tests show that printing the client test page from CUPS HTTP GUI does work, even if the "Filter failed" message still appears client-side.

Only difference is that my server now runs XFCE - it used to run GNOME in fallback mode (Acer Aspire Revo with no real graphic accel to speak of), and F21 doesn't have usable ways to tone down its need for graphic accel (no, llvmpipe makes the CPU of my tiny Revo way too busy to run a VNC session decently). Don't know if that's relevant but I thought I'd mention it anyway.

BTW, shouldn't this bug stay in something else than CLOSED ERRATA?
Comment 34 Tim Waugh 2015-05-08 06:30:33 EDT
Perhaps you did the configuration wrong?

The client set-up should simply be to add the 'ipp-client' and 'mdns' services to the firewall zone. After that, applications should discover the queue on the server and be able to print to it.

Some applications are using older toolkits which do not know how to perform this discovery (i.e. they don't use libcups). For those, you can use the cups-browsed service to automatically add local queues to forward jobs to discovered queues.
Comment 35 Alessandro Suardi 2015-06-05 04:54:07 EDT
Configuration was entirely done via CUPS GUI, both at server and at client.

I just found out that my printer has decided to spit out some unfiltered
 PDF instead of nice printouts for some files, so I

 - deleted printer at server ('torrent') and client

 - added printer at server, which goes like

HP Photosmart c4600 Series hpijs, 3.14.10 (color, 2-sided printing)
hp:/usb/Photosmart_C4600_series?serial=CN03NH200405G0

 - added printer at client, which goes like

HP Photosmart c4600 Series hpijs, 3.14.10 (color, 2-sided printing)
dnssd://HP%20Photosmart%20C4600%20series%20%40%20torrent._ipp._tcp.local/cups

Entirely dropped the firewall at server side via iptables -F, and the test
 page printing from the CUPS GUI at client says

 processing since
Fri 05 Jun 2015 10:49:44 AM CEST 
"Filter failed"
Comment 36 Alessandro Suardi 2015-06-05 05:01:35 EDT
...and performing

# lpadmin -pHP_Photosmart_C4600_series -m raw

 (this time correctly) on the client side allows my printing to go through.
Comment 37 Tim Waugh 2015-06-09 03:01:45 EDT
(In reply to Alessandro Suardi from comment #35)
> Configuration was entirely done via CUPS GUI, both at server and at client.

CUPS GUI? You mean the web interface, localhost:631?
Comment 38 Alessandro Suardi 2015-06-09 04:21:33 EDT
Yes - that's right, localhost:631 for my laptop client and torrent:631 for
 the Aspire Revo server.

I noticed I picked hpijs instead of hpcups this time around, though I don't
 think it should make a difference (it was both ways hpcups earlier on, it is
 both ways hpijs now) in the context of this specific issue.
Comment 39 Tim Waugh 2015-06-16 11:50:47 EDT
Essentially, you should only specify the driver once, and ideally at the server end. With system-config-printer I believe this is done correctly at the client end (i.e. using a raw queue, sending the job as-is to the server).
Comment 40 Alessandro Suardi 2015-06-17 05:51:10 EDT
I'm not sure I can agree here. The behavior of configuring via CUPS web the
 printers with drivers specified both at client and as server has worked
 flawlessly forever, up to F19 which broke stuff.

If F19 breakage is actually intended behavior change, then it's a CUPS web
 bug to let a user configure client-side driver without a big red flashing
 sign telling "are you sure? you should configure this driver ONLY at the
 server side AND set this printer up as RAW".

Which one would you pick? :)
Comment 41 Tim Waugh 2015-06-17 07:43:23 EDT
In fact we dropped a patch to work around this as it was causing other problems. What you are seeing is the upstream behaviour.
Comment 42 FrankS 2018-02-24 12:23:28 EST
I ran into the same error in Fedora Server 27 while printing from another distro (Ubuntu 16.04 LTS). Fedora client to Fedora Server prints without problems btw!. I support Tims theory (client to be configured with raw queue) because it solved the issue at my side. When I configured the client as Generic (local raw printer) I was able to print again without changing anything to my server configuration. Printing from Windows works fine too btw. On the client you see the error "filter failed" which seems to point to the ppd file, but raw printing solves. Hope this comment will help others running into the same issue.
Comment 43 bugz 2018-06-03 08:59:24 EDT
I had this error today, printing from Fedora 26 client to Fedora 27 Server.
I commented out the *Cups-Filter lines in the HP .ppd file at the client - Everything then worked as expected.

Took some time before I found this bug described here.

Note You need to log in before you can comment on or make changes to this bug.