Thursday, August 04, 2005

Printinng Issues

The inability to cancel a job could be attributed to the contents of
your /etc/inetd.conf file, specifically the in.lpd line. It has to be
uncommented AND it MUST refer to "tcp6" and not tcp. You should also
run the command pmadm -l and make certain there are no references to
tcp services. zsmon services are OK; they are for serial ports. TCP
services in this context can cause problems and should be removed.

Krishna, you report two problems. The second problem (can't
cancel print jobs) compounds the first (print jobs repeating
endlessly).

In most cases, the second problem is easier to fix than the
first, so it's a good place to start. Martha suggested the
correct entry in /etc/inetd.conf. The old-style TCP listener
daemons can also interfere with the operation of the cancel
command, and they are no longer used for printing. Run these
commands to disable the listeners to prevent them from causing
trouble:

pmadm -r -p tcp -s lpd
pmadm -r -p tcp -s lp
pmadm -r -p tcp -s 0 (that's the number zero)

See if that helps the problem with the cancel command.

The problem with the repeated print jobs is something I've
seen happen with the HP Jetdirect/HPPI software. If you
look in the file /opt/hpnpl/README.UNX, you'll find some
very interesting reading in Section III:

************************************
III. ISSUES/SOLUTIONS/WORKAROUNDS
************************************
.
.
.
3. Issue: Job get printed more than once in LaserJet 8500,
1100 and 2500CM printer.

Solution: Turn off Job recovery for the printer queue. In
this case, jobs will not get recovered if there is
power failure.
.
.
.
6. Issue: Large job prints again and again and gives
"Connection reset by peer" error in LJ4500 when
time out is set to 90sec in printer front panel.

Workaround: Increase the idle-timeout value by increments of
90sec on the HP Jetdirect. If the maximum value of
3600sec does not resolve issue, then try 0sec.

7. Issue: Jobs are printed multiple times by hpnpf if the
printer is offline for long time.

Workaround: Increase the idle-timeout value by increments of
90sec on the HP Jetdirect. If the maximum value
of 3600sec does not resolve issue, then try 0sec.

Perhaps one of those workarounds suggested by HP will help...

Since I received some replies to my previous summary,
I include a second summary including them, since they may
be of interest to some of you.

Basically:

Tim Henrion said:

I missed your original question when it was sent to the list. We had
this same problem and fixed it the same way as you did. The problem
was caused by the listener not running. Check out the man pages for
listen and nlsadmin to learn more.

And Mathew Stier was kind enough to include the setup procedure
to manually define a printer on Solaris 2.5 (which I include at the end
of this mail).

Definitely, it seems that some of these steps is performed by admintool
but not by jetadmin install printer.

Hope this summary is usefull for someone else there.
Mariel

ORIGINAL POST

I hope this is an easy and stupid thing that I am doing.
I am trying to install an HP 4V network printer.
I installed jetadmin.
I defined the printer using jetadmin (all the files under /etc/printers
are created ok).
When I type: lpq, after waiting for a long time, I get the following
message:
could not talk to print service at 'machine_name'

When I try to print something using lpr -P printer filename, I get on
the console the follwoing message:
Error transfering print job 1
check queue for (printer_name@machine_name)
I shut down and restared the lpsched hundred of times already, and even
rebooted the machine (just in case) to no avail.
Any ideas?

FIRST SUMMARY

I am still puzzled about this problem. I don't think I found a solution
but just a workaround.
If you have a machine, that was never defined as printer server before,
you install jetadmin, and then define a printer via jetadmin, you get
this error.
This happens no matter which version of jetadmin you use (I tried with 3

of them including the last one 3.15).
The workaround is to define another printer (even a non existing one)
using admintool.
This makes the lpq and the rest of the commands start working, and you
are able to use the network printer without any problems, even if
afterwards you
delete that extra printer.
I think that the problem might be something that is done when admintool
defines a printer that the "add printer" of jetadmin doesn't do, but I
do not know what it
is.

PRINTER SETUP PROCEDURE

INFODOC ID: 2097

SYNOPSIS: Solaris 2 printer configuration commands - quick reference
DETAIL DESCRIPTION:

Setting up local printers under Solaris 2.x.

Some of these steps are only for information: they're commented out.
Most of this has to be done as root.

Format is English description, then 2.x command on the right.

Check general printer status lpstat -s

If not running, start /etc/init.d/lp start

# To stop all print services /etc/init.d/lp stop

Show all printers configured lpstat -p all

Show a particular printer lpstat -p myprinter

Show a particular printer in detail lpstat -p myprinter -l

Check port monitor services pmadm -l

Turn off the portmonitor on ttyb pmadm -d -p zsmon -s ttyb
pmadm FLGS changes to 'ux'

# To turn ON the portmonitor on ttyb pmadm -e -p zsmon -s ttyb
# pmadm FLGS changes to 'u'

Add a new printer on ttyb cd /dev/term
chgrp lp b; chown lp b; chmod
660 b
lpadmin -p myprinter -v
/dev/term/b

Send the output to a file touch /tmp/printout
instead chmod 666 /tmp/printout #
temporary
lpadmin -p myprinter -v
/tmp/printout

# Remove a printer lpadmin -x myprinter

To enable enable myprinter

To accept jobs accept myprinter

To check status (again !) lpstat -p myprinter

To print something lp -d myprinter /etc/passwd

Allow normal users to print without lpadmin -p myprinter -o nobanner

banners (otherwise, only root can
print without banners)

Fix up the serial line settings lpadmin -p myprinter (still no
banner) -o
"nobanner stty='cs8 19200'"

Add a description lpadmin -p myprinter -D 'My new
printer'

Make it the system default destination lpadmin -d myprinter

At this point it should be possible to print a job and have it
appear either in /tmp/printout (if that's the output device) or
on the printer.

Adding filters

The scheduler attempts to match the type of job beingprinted to
the type of the printer. If it does not find one, it prints an
error message:

# lp -d myprinter -T ps /etc/passwd
UX:lp: ERROR: There is no filter to convert the file content.
TO FIX: Use the lpstat -p -l command to find a
printer that can handle the file type
directly, or consult with your system administrator.

# To force a filter to be applied to a job, define: The type of
the
input job The type of data which the printer can accept To
print
HPGL toan OSE6450 printer, the HPGL must be followed by the
string
'\033%-12345x' (The first character is ESCAPE.) This can be
accomplished as follows:

Define the printer as taking ose lpadmin -p myprinter -I ose
data. The printer will only
print data type ose: the scheduler
must find a filter to print other
types of data to this printer.

Make a directory for local filters mkdir /usr/lib/lp/local

Add a suitable filter cd /usr/lib/lp/local
cat >hpgl2ose
#!/bin/sh
#echo anything to send before
the job

cat -
echo '\033%-12345'
exit 0
^D

Make it executable, etc. cd /usr/lib/lp/local

Make it executable, etc. chmod 755 hpgl2ose
chown lp hpgl2ose; chgrp lp
hpgl2ose

Add a suitable filter definition cd /etc/lp/fd
cat >hpgl2ose.fd
# comments here
Input types: hpgl
Output types: ose
Printer types: any
Printers: any
Filter type: fast
Command:
/usr/lib/lp/local/hpgl2ose
Options: PRINTER * = -p*
^D

chown lp hpgl2ose.fd
chgrp lp hpgl2ose.fd
chmod 664 hpgl2ose.fd

Add it to the list of filters the lpfilter -f hpgl2ose system
knows
about
-F /etc/lp/fd/hpgl2ose.fd

Check the filters that the system lpfilter -f all -l
recognizes

Check just one filter lpfilter -f hpgl2ose -l

# Remove a filter lpfilter -f hpgl2ose -x

Check the output from the spooler lpadmin -p myprinter -v
/tmp/printout

(printer is default dest)
cp /dev/null /tmp/printout lp -T hpgl
-o nobanner /etc/passwd
cat -v /tmp/printout

Check that this file will print sleep 30000 </dev/term/b &
ok if required (stty settings will stty cs8 19200 </dev/term/b
vary) cp /tmp/printout /dev/term/b

check the output tray
ps -efl | grep 30000
kill sleep-pid

Point the printer back at the lpadmin -p myprinter -v
/dev/term/b
serial line

Configuring a print server

Format is English description, then 2.x command below (since the
commands
are too long to go on the same line).

Install patch 100863 and append this line to /etc/lp/Systems:

+:x:-:s5:-:n:10:-:-:Allow all connections

Check it works :

# lpsystem -l
System: +
Type: s5
Connection timeout: never
Retry failed connections: after 10 minutes
Comment: Allow all connections
#

Identify the "listen" port monitor version number (typ. 4)

# nlsadmin -V
4
#

Show all port monitors: this shows typical output:

# sacadm -l
PMTAG PMTYPE FLGS RCNT STATUS COMMAND
zsmon ttymon - 0 ENABLED
/usr/lib/saf/ttymon #
#

Show tcp "listen" port monitors

# sacadm -l -p tcp
Invalid request, tcp does not exist
#

Add a listen port monitor if not present

# sacadm -a -p tcp -t listen -c "/usr/lib/saf/listen tcp" -v 4

Show tcp "listen" port monitors

# sacadm -l -p tcp
PMTAG PMTYPE FLGS RCNT STATUS COMMAND
tcp listen - 0 STARTING
/usr/lib/saf/listen tcp
#

#

Get the print server's universal address (in hex)

# lpsystem -A
00020203819c88fb0000000000000000
#

Add aBSD listener, if required. The '4' is from 'nlsadmin -V' above.

# pmadm -a -p tcp -s lpd -i root -v 4 -m `nlsadmin -o
/var/spool/lp/fifos/listenBSD -A
"\x00020203819c88fb0000000000000000"`
#

or (in sh, if you cannot cut and paste)

# ad=`lpsystem -A`
# pmadm -a -p tcp -s lpd -i root -v 4 -m `nlsadmin -o
/var/spool/lp/fifos/listenBSD -A "\x$ad"`
#

Check that this has taken effect

# pmadm -l -p tcp -s lpd
PMTAG PMTYPE SVCTAG FLGS ID <PMSPECIFIC>
tcp listen lpd - root
\x00020203819c
88fb0000000000000000 - p - /var/spool/lp/fifos/listenBSD #
#

To remove the listener at any time, use

# pmadm -r -p tcp -s lpd

To add System V clients, add the STREAM service used for print requests.

The '4' is from 'nlsadmin -V' above.

# pmadm -a -p tcp -s lp -i root -v 4 -m `nlsadmin -o
/var/spool/lp/fifos/listenS5`
#

Check that this has taken effect

# pmadm -l -p tcp -s lp
PMTAG PMTYPE SVCTAG FLGS ID
<PMSPECIFIC>
tcp listen lp - root - - p -
/var/sp

ool/lp/fifos/listenS5 #
#

Figure out the address to use for service 0, the nlps server.

# lpsystem -A
00020203819c88fb0000000000000000
#

which divides into:

0000000000000000 16 zeros for padding
819c88fb Server's IP address in hex
0203 BSD printer port == 515
0ACE SysV printer port == 2766
0002 INET protocol family

The BSD listener uses the 515 port as reported by 'lpsystem -A' - the
System V spooler uses 2766, so theaddress must be changed to

00020ACE819c88fb0000000000000000

The "\x" is added to force it to be interpreted in hex.

Add service 0, the nlps server

# pmadm -a -p tcp -s 0 -i root -v 4 -m "`nlsadmin -c
/usr/lib/saf/nlps_server -A '\x00020ACE819c88fb0000000000000000'`"
#

Check that this has taken effect

# pmadm -l -p tcp -s 0
PMTAG PMTYPE SVCTAG FLGS ID
<PMSPECIFIC>
tcp listen 0 - root
\x00020ACE819c
88fb0000000000000000 - c - /usr/lib/saf/nlps_server #
#

To remove the System V listener at any time, use

# pmadm -r -p tcp -s lp
# pmadm -r -p tcp -s 0

Configuring a print client of a BSD print server

Register the print server name with the print service

# lpsystem -t bsd bsdserver
"bsdserver" has been added
#

To remove the print server, use

# lpsystem -r bsdserver
Removed "bsdserver".
#

To check what's been added

# grep bsdserver /etc/lp/Systems
bsdserver:x:-:bsd:-:n:10:-:-:
#

Add the printer to the client system. This information is entered into
the directory /etc/lp/printers by the lpadmin command.

# lpadmin -p local_prt_name -s bsdserver!rmt_prt_name

To remove the printer, use

# lpadmin -x local_prt_name

Set the printer's content and type

# lpadmin -p local_prt_name -T unknown -I any

Allow queuing

# accept local_prt_name

Enable the printer

# enable local_prt_name

Check the configuration

# lpstat -p local_prt_name -l
printer local_prt_name is idle. enabled since Sun May 9 17:50:15 BST
1993. available.
Content types: any
Printer types: unknown
Description:
Users allowed:
(all)
Forms allowed:
(none)
Banner not required
Character sets:
(none)
Default pitch:
Default page size:

Configuring a print client of a System V print server

Register the print server name with the print service

# lpsystem -t s5 sys5server
"sys5server" has been added
#

To remove the print server, use

# lpsystem -r sys5server
Removed "sys5server".
#

To check what's been added

# grep sys5server /etc/lp/Systems
sys5server:x:-:s5:-:n:10:-:-:
#

Add the printer to the client system. This information is entered into
the directory /etc/lp/printers by the lpadmin command.

# lpadmin -p local_prt_name -s sys5server!rmt_prt_name

To remove the printer, use

# lpadmin -x local_prt_name

Set the printer's content and type

# lpadmin -p local_prt_name -T PS -I PS

Register bundled PostScript filters using the lpfilter command. From
sh:

# cd /etc/lp/fd
# for filt in `ls | sed 's/\.fd//'`
> do
> lpfilter -f $filt -F $filt.fd
> done
#

Check the filters have been added

# lpfilter -f all -l

Allow queuing

# accept local_prt_name

Enable the printer

# enable local_prt_name

Check the configuration

# lpstat -p local_prt_name -l
printer local_prt_name is idle. enabled since Sun May 9 17:50:15 BST

1993. available.
Content types: any
Printer types: unknown
Description:
Users allowed:
(all)
Forms allowed:
(none)
Bannernot required
Character sets:
(none)
Default pitch:
Default page size:

Attention print queue gurus --

I have a few HP printers queued on my 2.6 Solaris Ultra-60 box, configured
using jetadmin from HP. They've been working fine for many months (some
for years), until yesterday.

A user tried to print a file yesterday, and it is now repeatedly coming
out on their printer. They've had to shut the printer off.

I tried to cancel the print job with `cancel -u cbartley', and after about
twenty seconds I get:
could not talk to print service at biocomp
which repeats another three times.

I get the same error message (although just once) with `lpq -P papowers'.

I tried stopping and starting the scheduler with `lpshut' and
`/usr/lib/lp/lpsched'. No difference.

In /var/spool/lp/logs/lpsched, I see:
11/28 14:24:35: printer fault. type: write root, status: 14
msg: (exec exit fault)

I searched DejaNews and came up pretty much empty-handed. More info:

---------------------------------
A `ps -ef | grep lp' yields:
---------------------------------
cbartley 11950 11949 0 10:58:54 ? 0:00 /bin/sh -c
/etc/lp/interfaces/papowers papowers-67 biocomp!cbartley "67-1" 1 "
root 11949 11943 0 10:58:54 ? 0:00 /usr/lib/lpsched
cbartley 11973 11972 0 10:58:54 ? 0:00 /bin/sh -c
/etc/lp/interfaces/papowers papowers-67 biocomp!cbartley "67-1" 1 "
cbartley 11996 11975 0 10:58:55 ? 0:00 cat
/var/spool/lp/tmp/biocomp/67-1
root 11943 1 0 10:58:54 ? 0:00 /usr/lib/lpsched
cbartley 11972 11951 0 10:58:54 ? 0:00
/usr/spool/lp/bin/lp.tell papowers
cbartley 11951 11950 0 10:58:54 ? 0:00 /bin/sh -c
/etc/lp/interfaces/papowers papowers-67 biocomp!cbartley "67-1" 1 "
cbartley 11975 11974 0 10:58:54 ? 0:00 /usr/bin/sh
/etc/lp/interfaces/model.orig/papowers papowers-67 biocomp!cbartley

---------------------------------
A `lpstat -t' yields:
---------------------------------
scheduler is running
system default destination: hp3147
system for _default: biocomp (as printer hp3147)
device for hp2116: /dev/hp2116
device for hp3210: /dev/hp3210
device for hp3147: /dev/hp3147
device for papowers: /dev/papowers
hp3147 accepting requests since Fri Dec 18 14:01:06 CST 1998
hp2116 accepting requests since Mon Apr 19 15:04:57 CDT 1999
hp3210 accepting requests since Fri Dec 18 14:02:33 CST 1998
papowers accepting requests since Mon Jul 10 14:42:10 CDT 2000
printer hp3147 is idle. enabled since Tue Apr 20 10:19:38 CDT 1999. available.
printer hp3210 is idle. enabled since Fri Dec 18 14:02:33 CST 1998. available.
printer hp2116 is idle. enabled since Mon Apr 19 15:04:57 CDT 1999. available.
printer papowers now printing papowers-67. enabled since Wed Nov 29
08:08:31 CST 2000. available.
papowers-67 cbartley 163135 Nov 28 14:20 on papowers

---------------------------------
A `lpstat -p papowers -l' yields:
---------------------------------
printer papowers now printing papowers-67. enabled since Wed Nov 29
08:08:31 CST 2000. available.
Form mounted:
Content types: simple
Printer types: unknown
Description:
Connection: direct
Interface: /usr/lib/lp/model/net_ljx000
After fault: continue
Users allowed:
(all)
Forms allowed:
(none)
Banner required
Character sets:
(none)
Default pitch:
Default page size:
Default port settings:

Any ideas about how I can fix this?

--
Jim Winkle, UNIX System Administrator, UW-Madison, DoIT. Contact info:

BioComp: help@biocomp.doit.wisc.edu http://www-biocomp.doit.wisc.edu/
Other: jwinkle@doit.wisc.edu http://jwinkle.doit.wisc.edu/

Problem restatement:
---------------------
A user printed a file once, but the file continued to come out of their
printer, consuming much toner and a small forest. Trying to cancel the
print job with `cancel' yielded (after a 30 second delay):
could not talk to print service at biocomp

Solution:
---------------------
# lpshut
# rm -r /var/spool/lp/tmp /var/spool/lp/temp /var/spool/lp/requests
# /usr/lib/lpsched

Starting lpsched recreated those directories I deleted.

I'm still getting the error message (and 30 second delay):
could not talk to print service at biocomp
with cancel and lpq, but this may be a seperate problem. 'biocomp' is
the name of the UNIX box on which the printer is queued (same box as I
am executing cancel/lpq on). If anyone has any ideas, send 'em my way.

Cause of the problem:
---------------------
Most likely caused by a network hangup, which lasted longer than
the printer timeout. Here's how it should work. The spooler sends the
the print job to the printer, which gets broken up into tcp packets. The
printer accepts these packets as it can, handshaking with the server.

If there is REALLY slow network response (as in a network storm), the
server doesn't get the response in time, assumes the printer didn't
get the file, and resends it. The printer itself prints the original,
and the retransmission of it. Things can get pretty confused, and
the spooler can end up sending endless copies of part of or a whole file.

Thanks much to respondants!

"Could not talk to print service" errors
All 2 messages in topic - view as tree

kprasa Sep 7 2000, 6:44 pm show options
Newsgroups: comp.sys.sun.admin
From: kpr...@my-deja.com - Find messages by this author
Date: Thu, 07 Sep 2000 22:26:33 GMT
Local: Thurs, Sep 7 2000 6:26 pm
Subject: "Could not talk to print service" errors
Reply to Author | Forward | Print | Individual Message | Show original
| Report Abuse

I am trying to move a print server from one machine to another. On the
new machine, which is running Solaris 8, I get the following error when
I type in lpq "Could not talk to Print Service at <hostname>"
lpstat -a shows me that all the printers are accepting requests. I can
print to the printers from workstations around. I cannot seem to get
the queue status.
/usr/lib/lpsched is running and all printers have been enabled.

What am I missing. Any suggestions would help.

Thanks

Kiran"Could not ta

Sent via Deja.com http://www.deja.com/
Before you buy.


Greg Andrews

<hostname> is probably not accepting connections on TCP port 515,
the printing port. Or you have a packet filter that was opened
to allow the old print server to connect to the printers, but
not the new one.

-Greg

John Martin

Ah the joys of the Solaris print spooler.

It's been a while since I did this so I might be a bit rusty, here goes.

Shut down the spooler with lpshut

cd to /var/spool/lp/requests/<hostname>

Within this directory will be the request file which indicates to the
spooler that there is a request waiting to be serviced. It will be named
with the request number (67-0 I think). If you delete or move this file
somewhere else then it effectively removes the request from the queue.

cd to /var/spool/lp/tmp/<hostname>

Within this directory will be a temporary file which holds details about the
print job, including the name of the file being printed. It too will be
named with the request number (67-0 I think). Move this file elsewhere in
case you need to refer to it later.

Do a ps and grep for lp just to make sure they're all gone.

Restart the spooler and do an lpstat to check the queue entries.

If your spooler makes a copy of the print file before printing it then you
may need to manually remove it, refer to the request details saved above.

As for your original problem, I have seen this sort of behaviour exhibited
on some of our printers in the past. In our case it was down to slow network
response and the setting of the printer timeout. Basically what happens is
that the spooler sends the request to the printer, if the print file is
large enough then it will wait for a response to say that it has started
printing and to send more please. Due to slow network response the reply
doesn't get through in time so the spooler does a retry thinking that it has
failed the first time etc etc.

I'm sure that you can up the timeout in the jetdirect interfaces through
jetadmin so try looking there.

Hope this helps.

JJ

Here are the two ways for solaris 2.6 and later, printing to an
HP network printer that supports Postscript:

1:

lpadmin -p printername -v /dev/null -m netstandard -o protocol=bsd -o dest=printer-ip-address -T PS -I postscript

enable printername
accept printername

Note that the last argument to the lpadmin command is -I, which is
a capital letter "eye", not a lowercase letter "ell" or the number
"one".

If the HP printer doesn't support Postscript, change the last two
arguments in the lpadmin command to:

-T hplaser -I any (if you're going to print PCL formatted files)
-T hplaser -I simple (if you're going to print only plain text)

2:

Add an entry to /etc/hosts (or your NIS/NIS+ hosts table, or your DNS)
that gives a hostname to the printer's IP address

lpadmin -p printername -v /dev/null -m netstandard -o protocol=bsd -o dest=printer-hostname -T PS -I postscript

enable printername
accept printername

See the notes above for variations of the lpadmin arguments. Notice
that only the "-o dest=xxxx" argument changed between the two ways.

With HP printers, it's usually best to download and install HP's
Jetadmin software for Solaris. It supports mode of the printer's
features than the stock Solaris print systems does. Then add the
printer through Jetadmin's text interface instead of typing the
above commands.

-Greg
--

Fil Krohnengold

I've gotten some help, but I'm still having trouble. here's what I'm
doing:

research:~> lpadmin -p netsyslp2 -m netstandard -v /dev/null -o protocol=bsd -o dest=the_real_ip_addr -T PS -I postscript

I've actually tried this a few times without the -T and -I options.
So here's where i get confused:

research:~> enable netsyslp2
destination "netsyslp2" now accepting requests
research:~> accept netsyslp2
UX:accept: WARNING: Destination "netsyslp2" was already accepting
requests.
[Hmm...]
research:~> lpstat -p netsyslp2
printer netsyslp2 disabled since Sat Nov 6 23:35:27 EST
1999. available.
new printer

And that's it. The printer stays "disabled". And if I send a job to
it, it's stuck in the queue now for ever.

research:~> lpstat -R
1 netsyslp-1 fil 4924 Nov 04 15:22
1 netsyslp1-2 fil 4924 Nov 04 16:10
research:~> cancel netsyslp1-2
could not talk to print service at research
research:~>

Tried restarting lpsched too. Sad.

Anyone?

-fil

I'm trying to configure a printer spool on a SUN Sparc running SunOS 5.5.1
and am receiving the following error when trying 'lpq -P<queuename>':

could not talk to print service at <print server name>

I've tried both local and remote spools and get the same error (only the
server name changes appropriately).

However, this problem doesn't occur for the superuser -- only regular
users get this problem. This seems to indicate that some file permissions
are set incorrectly. I checked for 'r-x' permissions for everybody in the
following places:
/var/spool/print
/etc/lp
/etc/lp/model
/etc/lp/interfaces

Does anyone know what my problem is and how I can fix it?

Thanks,

Trevor Wood

suggestion; this is solaris. learn the native commands.

lpadmin, lpstat, lpsystem.

try lpstat -o printername

Then if that doesn't work, try using
truss lpstat -o printername

to find out where it is bombing

-

Sorry that I lose the original thread. To works as a print server,
you need to configure /etc/lp/Systems by lpsystem, and saf by sacadm
and pmadm. Did you do all these?

The spec on RFC1179 for LPD ensures that any LPD connections must be in the
range of 721 - 731 inclusive. If your `lpq' is executed at the user level and
is an lpq that speaks to a REMOTE LPD, then your connection will be refused
because user-level port restrictions.

Most often lpq's talk to the local LPD which is running as root which in turn
talks to the remote LPD.

Ensure that your version of lpq does in fact talk to the local LPD, not the
remote LPD. Otherwise, you may indeed have to suid your lpq binary. I've
heard of some lpq's just referencing the printcap for the rm,rp entries
instead of talking to a local LPD. This IMHO is more an error with LPD
RFC1179 than anything else.

I don't know if this is it, but try it and find out.


joeh
I thought lpd is listening at port 515 ??

-

joeh wrote:
> I thought lpd is listening at port 515 ??

> "J. S. Jensen" wrote:
> > The spec on RFC1179 for LPD ensures that any LPD connections must be in the
> > range of 721 - 731 inclusive. If your `lpq' is executed at the user level and

Yes, the listening port IS at 515, however, the RECEIVING CLIENT port
(yes, it is
specified, if you can believe that) must be 721-731.

> > is an lpq that speaks to a REMOTE LPD, then your connection will be refused
> > because user-level port restrictions.

Unfortunately this is why a lot of LPD queries fail.

My /etc/services file has this line:

printer 515/tcp spooler # line printer spooler

Do i also need to add the client statement to this file?
Just checking before i presume
Does anyone have a copy of the line in their /etc/services file?
Using SunOS 5.7 ("solaris 7")
Thanks to anyone willing to help
Joe

joeh wrote:
> My /etc/services file has this line:
> printer 515/tcp spooler # line printer spooler
> Do i also need to add the client statement to this file?

No, not at all, as you well know, the services file allows for
particular daemons to
reference port numbers by names.

The daemon LPD itself checks the connecting client port. Or at least
it /should/
according to spec. I've personally written LPDs where I ignore the client port
restriction.

--

>My /etc/services file has this line:

>printer 515/tcp spooler # line printer spooler

>Do i also need to add the client statement to this file?
>Just checking before i presume
>Does anyone have a copy of the line in their /etc/services file?
>Using SunOS 5.7 ("solaris 7")

No, you don't need to add anything else to that file. Both servers
and clients only use the first two fields, which are the same for
both.

-Greg

12 Comments:

Blogger Kathiresan Muthu said...

Awesome Blogs share more information and refer the link Android Training in Chennai

8:15 AM  
Blogger Abina Ragav said...

This information is impressive..I am inspired with your post writing style & how continuously you describe this topic. After reading your post,thanks for taking the time to discuss this, I feel happy about it and I love learning more about this topic
Android Training in Chennai

8:08 AM  
Blogger Giri Mani 2 said...

This blog is having the general information. Got a creative work and this is very different one. We have to develop our creativity mind. This blog helps for this.
Thank you for this blog. this is very interesting and useful.
Android Training in Chennai

4:57 AM  
Blogger deeksha said...

This blog is very much infinitive thanks for sharing those your information ,it is interesting , it is nice too.




android training in chennai


5:14 AM  
Blogger Ridhima said...


All are saying the same thing repeatedly, but in your blog I had a chance to get some useful and unique information, I love your writing style very much, I would like to suggest your blog in my dude circle, so keep on updates.


Java training in Adyar

9:24 AM  
Blogger rakesh said...

nice blog..
SAS Institute introduced the SAS Certified Professional Program,training proper understanding of how the SAS software works. Among the five certification programs that SAS Institute has come up with, SAS training can be considered as the entry point into the big data and the data analytics industry.
SAS online training in hyderabad

5:32 AM  
Blogger rakesh said...

very interesting blog...
SAS Institute introduced the SAS Certified Professional Program,training proper understanding of how the SAS software works. Among the five certification programs that SAS Institute has come up with, SAS training can be considered as the entry point into the big data and the data analytics industry.
SAS online training in hyderabad

5:33 AM  
Blogger Rakesh S said...

so many of printing issues are there here there is an option to slove..
Hadoop training in hyderabad.All the basic and get the full knowledge of hadoop.
hadoop training in hyderabad

12:58 AM  
Blogger navya said...

EXcellent post thanku for shariong this nice posts..informatica online training




2:27 AM  
Blogger vignes waran said...


Excellent article. we could be sharing now amazing users posting.I got catch it knowledgeful points.

Hadoop Training
Hadoop Course in Chennai

12:25 AM  
Blogger vignesjose said...

Great Article… I love to read your articles because your writing style is too good, it is very very helpful for all of us and I never get bored while reading your article because they become a more and more interesting from the starting lines until the end.
Selenium Training in Chennai
Selenium Course in Chennai

2:02 AM  
Blogger Catherine Higgins said...

Thank you for sharing such a nice and interesting blog with us. i have seen that all will say the same thing repeatedly. But in your blog, I had a chance to get some useful and unique information
We at Colan Infotech Private Limited best web design company in chennai,is Situated in US and India, will provide you best service in
Professional Website Design Services and Colan Infotech has a group of exceedingly dedicated,
inventive and creative experts with an energy for delivering exciting , helpful and stylish Web and Mobile Applications,
We provide all sort of web designing services in chennai and
of course we stepped in bangalore too we are best website designers in bangalore can provide web design services in bangalore, hire web designer india

7:56 AM  

Post a Comment

<< Home