Bug 26921 - printing to remote printer doesn't work
Summary: printing to remote printer doesn't work
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: printconf   
(Show other bugs)
Version: 7.1
Hardware: i386 Linux
Target Milestone: ---
Assignee: Crutcher Dunnavant
QA Contact: David Lawrence
Depends On:
TreeView+ depends on / blocked
Reported: 2001-02-10 06:30 UTC by Jeremy Katz
Modified: 2007-04-18 16:31 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2001-02-13 15:46:04 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
/etc/printcap off of machine B (353 bytes, text/plain)
2001-02-13 00:50 UTC, Jeremy Katz
no flags Details
mf.cfg from machineB (402 bytes, text/plain)
2001-02-13 00:51 UTC, Jeremy Katz
no flags Details
zcat'd local.adl from machineB (899 bytes, text/plain)
2001-02-13 00:53 UTC, Jeremy Katz
no flags Details

Description Jeremy Katz 2001-02-10 06:30:59 UTC
Setting up a remote lpd queue via printconf does not result in a working
printer config (tested with an hp lj6 and filters configured on both ends).
 Printing via 'lpr -Plp@host foo' works fine.  Output from lpq -L is as

 Status: subserver pid 4235 starting at 00:42:12.211
 Status: accounting at start at 00:42:12.211
 Status: opening device '/dev/lp0' at 00:42:12.211
 Status: printing job 'root@rivendell+668' at 00:42:12.212
 Status: processing 'dfA668rivendell.ncssm.net', size 594564, format 'f',
IF filter 'mf_wrapper' at 00:42:12.212
 Status: IF filter 'mf_wrapper' filter msg - 'can't print HP PCL printer
data - US letter page size files' at 00:42:12.255
 Status: IF filter 'mf_wrapper' filter msg -
'/usr/share/printconf/mf_wrapper: exit: bad non-numeric arg `RETVAL'' at
 Status: IF filter 'mf_wrapper' filter exit status 'UNKNOWN STATUS '128''
at 00:42:12.259
 Status: printing finished at 00:42:12.260
 Status: accounting at end at 00:42:12.260
 Status: finished 'root@rivendell+668', status 'UNKNOWN STATUS '128'' at
 Status: subserver pid 4235 exit status 'UNKNOWN STATUS '128'' at 00:42:12.261
 Status: job 'cfA668rivendell.ncssm.net' error 'aborting operations' at
 Status: removing job 'cfA668rivendell.ncssm.net' - ABORT at 00:42:12.278

Comment 1 Glen Foster 2001-02-12 23:00:12 UTC
This defect is considered MUST-FIX for Florence Release-Candidate #1

Comment 2 Crutcher Dunnavant 2001-02-13 00:03:57 UTC
Please attach a copy of:

and the output of:
bzcat /etc/alchemist/namespace/printconf/local.adl

Comment 3 Crutcher Dunnavant 2001-02-13 00:23:30 UTC
also, where you sending non-standard data? (Like, say, PCL?)

Comment 4 Jeremy Katz 2001-02-13 00:49:24 UTC
Attachments coming right up, but to be a bit more verbose about the setup.  Note
that this setup worked properly with 7.0, so it's entirely possible someone
could end up with such a configuration

MachineA has printer plugged into parallel port, printer is configured as 'lp'
with filter configuration set up for the HP LaserJet 6L.  Printing from MachineA
works fine.

MachineB has remote lpd spool set up in printconf.  Remote spool is lp@MachineA
with filter config for the HP LaserJet 6L.

Comment 5 Jeremy Katz 2001-02-13 00:50:35 UTC
Created attachment 9860 [details]
/etc/printcap off of machine B

Comment 6 Jeremy Katz 2001-02-13 00:51:49 UTC
Created attachment 9861 [details]
mf.cfg from machineB

Comment 7 Jeremy Katz 2001-02-13 00:53:09 UTC
Created attachment 9862 [details]
zcat'd local.adl from machineB

Comment 8 Crutcher Dunnavant 2001-02-13 10:31:54 UTC
Right, there was an error in mf_wrapper, but that isn't what's killing you.
What are you printing? Is it raw PCL, because:

Status: IF filter 'mf_wrapper' filter msg - 'can't print HP PCL printer data -
US letter page size files' at 00:42:12.255

Implies that it is, in fact, raw PCL, that you are sending. Now, this printer
supports raw PCL, but the database scan can't see that, because it's not listed
as doing so. If you wish to force it to send raw PCL (or whatever) without
filtration (and all it's magic), set up a Raw print queue on machine B, and it
won't reject the job. I will try to get better prediction of capabilities.

But is it PCL that you are printing? What are you printing with? (is it gimp?)

Comment 9 Jeremy Katz 2001-02-13 15:09:11 UTC
It's raw pcl as it's already been processed by the print filters on machine B.
The abort occurs in the filters on machine A (which isn't clear from the lpq
log, bleah, sorry about that).  The print job in question is nothing more than
the postscript test page being printed from within printconf-gui, but the same
occurs whenever your print a postscript file off of machineB as the local
filters on machine B process it to PCL and then shove it across the network to

Comment 10 Tim Waugh 2001-02-13 15:26:19 UTC
You'll have to make a raw printer queue.  lp -oraw seems to be completely broken
right now. :-(

Comment 11 Jeremy Katz 2001-02-13 15:45:54 UTC
Which will foul up a lot of people's existing configurations when they upgrade :(

Comment 12 Crutcher Dunnavant 2001-02-14 06:57:21 UTC
I dont want to just let PCL through, I have no reason to assume that a given
printer supports it, except for a few clues in the pnp information.

This is a bad magic versus dangerous control character problem, and either way I
handle it, it's gonna piss off somebody. Okay, fine. I'll let PCL, PJL, et all

And if I get bugs on that behaviour (and I will, and they will be hard to
classify), I'll mark 'em WONTFIX.


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