Printer problems

[millsm]

"Edited to comply with ITRC Guidelines"
We receive upgrades from our HQ for the HPUX 11i every other month. The latest upgrade was very ugly and I think it broke more then it fixed. Now, my printers no longer work. When I do an lpstat it comes back with connection down. But I can ping the printer and when I look at the printer is SAM everything is ok. I have another HPUX box that does not get the upgrades and it prints to the same printers without a problem. Your help is appreciated.

millsm@ngbva (/home/millsm)$lpstat ibm2
connection to ibm2 is down

no entries
millsm@ngbva (/home/millsm)$ping ibm2
PING ibm2: 64 byte packets
64 bytes from xx.xx.250.122: icmp_seq=0. time=2. ms
64 bytes from xx.xx.250.122: icmp_seq=1. time=2. ms
64 bytes from xx.xx.250.122: icmp_seq=2. time=1. ms

[Court Campbell]

Do all the printers not print, or do a few not print? I had this issue once, but it was that the printer ip had been changed for some reason and no one decided to tell me. I then changed the ip in /etc/hosts and all was back to normal.

[millsm]

all of the remote printers do not work. but all the network printers do work. its a strange problem.

[NMory]

Have you tried to restart the printer daemon? in the

#lpshut
#lpsched

This will clear all print queues!!

Also,
Check if the rlpdaemon is running in the systems where the remote printers are attached to...

Try to restart the inetd daemon:

#inetd -c

regards,

NM

[millsm]

No luck... any other ideas..
we were having some permission problems on another issue after the upgrade...??

millsm@ngbva (/home/millsm)$lpshut
scheduler stopped
millsm@ngbva (/home/millsm)$lpsched
scheduler is running
millsm@ngbva (/home/millsm)$inetd -c
millsm@ngbva (/home/millsm)$lpstat ibm2
connection to ibm2 is down

no entries

[NMory]

This if from an ITRC's document:


In order to use remote printing, there must be a remote printing daemon
which is scheduled when a remote print request is received. This
daemon, "rlpdaemon", runs on the machine where the printer is located.
Check the file /etc/inetd.conf, and look for the following line:

# printer stream tcp nowait root /usr/lib/rlpdaemon rlpdaemon -i

If the "#" sign is there, this means the line invoking the rlpdaemon is
commented out; therefore, remote printing will not work. To resolve
this:

1. Edit the file /etc/inetd.conf
2. Remove the "#" sign from in front of the line so that the
line reads:

printer stream tcp nowait root /usr/lib/rlpdaemon rlpdaemon -i

3. Save the file
4. Execute the command:

/etc/inetd -c

to reconfigure the Internet daemon inetd, forcing it to
re-read the /etc/inetd.conf file.

Please check in the remote server or workstation where the printer is connected.

NM

[NMory]

Check #netstat -a

And look for ports whose destination IP address are the network printer and are in a "FIN_WAIT_2" state.

NM

[millsm]

what am I looking for?

millsm@ngbva (/etc/lp/member)$netstat -a | grep FIN_WAIT_2
tcp 0 0 ngbva.7779 ngvXXk-8bjaa011.2383 FIN_WAIT_2
tcp 0 0 ngbva.6003 ngbva.52165 FIN_WAIT_2
tcp 0 0 ngbva.49458 ngbva.49459 FIN_WAIT_2
tcp 0 0 ngbva.7779 ngvanb-x58c0001.4214 FIN_WAIT_2
tcp 0 0 ngbva.ftp ngva-pXX-ac09.2974 FIN_WAIT_2
tcp 0 0 ngbva.7779 ngvawk-8XXaa093.3597 FIN_WAIT_2
tcp 0 0 ngbva.49456 ngbva.49461 FIN_WAIT_2
tcp 0 0 ngbva.7779 ngvanb-8bjXX335.2733 FIN_WAIT_2
tcp 0 0 ngbva.7779 ngvanb-x5XX0001.4245 FIN_WAIT_2
tcp 0 0 ngbva.56234 ngbva.56238 FIN_WAIT_2
tcp 0 0 ngbva.56227 ngbva.62359 FIN_WAIT_2
tcp 0 0 ngbva.7779 ngvawk-pfXXp02.2024 FIN_WAIT_2
tcp 0 0 ngbva.7779 ngvawk-pfXXp02.2494 FIN_WAIT_2

[NMory]

Check the permissions of all the commands used to print.

E.g.
/usr/lib/rlp
lpstat
lp
etc...


Compare them with a good system

[NMory]

This means the client side (on this node) had sent a "FIN"
packet but it had not received an "ACK" for that "FIN".
The ports were still partially opened and could not be used
for other processes.

The network printer that did not gracefully close those TCP/IP connections.

[Court Campbell]

Sorry, i realize this doesn't resolve your issue. I just thought NMOry might be interested in this:

netstat -a | awk '/tcp/ {print $6}' | sort | uniq -c

[NMory]

If those connections belong to the printers or the systems where the remote printers are connected to, you can check the following document in ITRC which explains how to get rid of those FIN_WAIT_2 connections:

KBRC00015664
How do I clear or prevent too many fin_wait_2 connections?

NM