Bug 18936 - LPRng cannot print to Sun Solaris server
LPRng cannot print to Sun Solaris server
Product: Red Hat Linux
Classification: Retired
Component: LPRng (Show other bugs)
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Crutcher Dunnavant
David Lawrence
Depends On:
  Show dependency treegraph
Reported: 2000-10-12 03:03 EDT by loris.renggli
Modified: 2007-04-18 12:29 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2000-11-30 03:42:19 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description loris.renggli 2000-10-12 03:03:00 EDT
I have a Linux box with RH 7.0 (all available updates applied
as of Oct 10) and LPRng-3.6.24-2 talking to a Solaris 2.5 server
and cannot print.

There are _no_ error messages on the Linux side, but Solaris
says in /var/lp/logs/lpNet:

10/10 13:46:35 c 17716 pcipt710 request creation failed (cf: 78 bytes): No
such file or directory
10/10 13:46:35 c 17716 pcipt710 TLIWrite(connection) : orderly release

(pcipt710 is the name of the Linux computer).

This is the only error message I have been able to find; invoking
lpd and lpr with debugging turned on (-D5 option) did not show any

My printcap entry is (created with printtool):


I have tried to change the settings in various ways
without success (like: bk=true or no lpd_bounce).

We have been printing using the Sun host from Linux using
RedHat 5 and 6 which shipped with "standard lpr" without
any problems.
Comment 1 Crutcher Dunnavant 2000-10-19 11:15:26 EDT
I'm still trying to find a Solaris Box to play with, LPRng uses an extended lpd
protocol, to provide things like accounting, and 2 things pop to mind:
1) the Solaris box has a sloppy parser for its control files, causing the LPRng
extensions to screw it up,
2) the Solaris box has its OWN lpd extensions, which LPRng interacts badly with.

I will keep looking, but if this is critical to you (and it probably is, sigh)
you uninstall LPRng, and can install the old lpd daemon from 6.2 (I would
strongly suggest the latest errata (lpr-0.50-7.rpm), and all it's friends (the
6.2 tree's printtool, and rhs-printfilters).

If THAT doesn't let you print, then something is bad wrong.
Comment 2 Stewart Q Baillie 2000-10-25 18:56:03 EDT
I'm not sure if this is the same problem?

Remote printing via the lpd deamon running under SunOS Release 4.1.3_U1 has been
working fine for us for years under previous releases (5.2 and 6.1).  Now, with
7.0 installed, printing is fine to the Xerox device (as queue lpxf) but nothing
happens on the HP Laserjet device (4050N as queue lp2)    

And yes, I have read the release notes under 7.0 and rebuilt /etc/printcap using
the new printtool.  I have tried every variation of printcap options to the HP
device I can imagine, to no effect.  For the purposes of this report, I have
used the same basic postscript setting for both printers.

##PRINTTOOL3## REMOTE POSTSCRIPT 1200x1200 a4 {} PostScript Default {}
##PRINTTOOL3## REMOTE POSTSCRIPT 1200x1200 a4 {} PostScript Default {}

Under 7.0, after printing, lpq returns:

  [root@redfin-vt rh6.2]# lpq -Plp2
  Printer: lp2@redfin-vt (dest lp2@manta.vic.cmis.csiro.au)
   Queue: no printable jobs in queue
   Status: job 'root@redfin-vt+523' removed at 09:18:02.739 

So, there appears to be communication between the local and remote lpd daemons
(this is the same message as returned oin the lpxf queue where printing works). 
However, nothing prints when I use the printtool postscript test option or lpr

Unfortunately, I do not administer the Sun machine, so have limited access to
what is going on on that side.  Certainly no errors are reported.  It does seem
that the print job is not showing up on the remote print logs though.
Comment 3 Stewart Q Baillie 2000-10-25 20:01:48 EDT
Further on the HP Laserjet issue.  Following crutcher@redhat.com's suggestion, I
just reverted to the rh6.2 lpr rpms and printing works fine now.

I note the following entries on the Sun lpr log:

I'm not sure, (timestamp doesn't match) but I think this may have been produced
by an attempt to print using the 7.0 LPRng setup:

Debug /usr/local/etc/printers/print_hplj:  User root at Wed Oct 25 14:43:03 DST
Debug /usr/local/etc/printers/ditautoscan:  $_:  ;      24.194.138.in-addr.arpa
Debug /usr/lib/hpnp/hplj.if.sh.dit:  $FORMAT:  TEXT 

I believe a format of "TEXT" will not print on the HP Laserjet 4050N, so that
could be part of the story.  The other part is what the hell is
"24.194.138.in-addr.arpa" doing there?  Our subnet here is 138.194.24 by the

With the 6.2 LPR setup, a working remote entry is:

Debug /usr/local/etc/printers/print_hplj:  User root at Thu Oct 26 10:36:35 DST
Debug /usr/local/etc/printers/ditautoscan:  $_:  %!PS-Adobe-2.0
Debug /usr/lib/hpnp/hplj.if.sh.dit:  $FORMAT:  PS

Which looks rather better.

Hope this helps.

Comment 4 loris.renggli 2000-10-26 04:07:22 EDT
I reverted to lpr from 6.2 too, and it works fine.

My guess (but I haven't find anything to support that claim) is that
Sun's lpd extensions and LPRng extensions do not mix well; is there
any way to make LPRng work in "plain" lpd mode ?
Comment 5 Need Real Name 2000-11-27 14:40:28 EST
Additional comment, posted at the suggestion of RH support.
I have similar problems with RH7.0 printing via LPRng. I am upgrading an RH6.1 server 
that prints to a variety of networked printers. LPRng works fine printing to laserjets and 
deskjets on HP JetDirects (either way, lpd or direct port 9100). But it fails to print to 
an Oce printer which uses a closed DAC (digital access controller) box for lpd (the 
Ikon service guy says its just an OS2 box with Oce's software). Also failing to print is 
a postscript printer served by lpd on an old Sparcstation running SunOS4.1.3. 
Just to note: Up until now, all the lpr/lpd boxes can print among themselves 
(RH6, SunOS, NT4, Solaris, Macs with lpr-enabled Laserwriter drivers, Win2k, ...). 
OnlyRH7.0 with LPRng won't work.

When RH7 tries to print to SunOS4, there is an lpd log entry that the RH7 box 
"requests recvjob"; an email is sent to root@RH7 from daemon@SunOS with this 
message: "Your printer job (/usr/lib/rhs/rhs-printfilters/testpage.ps) could not be printed."
No other indications are given. 

Comment 6 Need Real Name 2000-11-29 12:53:39 EST
LPRng HOW-TO section 4.33 has the answer to my problem. Add the "bk" flag to printcap for the old 
bsd-style lpd printers. This flag makes LPRng send a backward compatible control file to the lpd.
Above printers now printing.
Comment 7 loris.renggli 2000-11-30 03:42:16 EST
Let me just recall (see my first posting) that I tried "bk" and it did
not work. So this is not a "universal" workaround (but of course,
it is worth trying).
Comment 8 Crutcher Dunnavant 2001-03-15 17:23:46 EST
the ability to set this flag is in the new printconf system.

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