Printing/networking/configuration problem?

[Ruben Cardenal]

Hi,

I posted this yesterday at "Print Servers" forum without any kind of response. I hope here at least someone can help :)

I have a "little" problem in one of my print servers. The server receives SAP printing jobs (and local UNIX printing ones), and, randomly, queues some of them, and the rest are printed. There seems not to a reason which made the server to print a job, and queue another. Jobs are queued even for months (I have a job of November 13th). I have tried restarting the print services, and changing (renice) the priority of the printing service (by redefining the priority of all proceses belonging to lp user) to the top, without exit. Any idea?

TIA

[Steven Sim Kok Leong]

Hi,

Try updating your lpsched to the latest cumulative patch. For HP-UX 11.00, it is as follows:

s700_800 11.00 lpspool subsystem cumulative patch

http://us-support3.external.hp.com/wpsl/bin/doc.pl/screen=wpslDisplayPatch/sid=cfb61dd10d896a4775?PACH_NAM=PHCO_25110&HW=s800&OS=11.00

Hope this helps. Regards.

Steven Sim Kok Leong

[Ruben Cardenal]

I installed the patch, and nothing changed. I have noticed this:

root@tareaap2:/yo# lpstat -t | grep dev/null
device for imr2: /dev/null
device for ec216: /dev/null
device for ct245: /dev/null
device for ct250: /dev/null
device for eh150: /dev/null
device for ap38: /dev/null
device for op04: /dev/null
device for ap17: /dev/null
device for ap06: /dev/null
device for eh64: /dev/null
device for eh33: /dev/null
device for eh38: /dev/null
device for eh63: /dev/null
device for eh15: /dev/null
device for am14: /dev/null
device for it21: /dev/null
device for it22: /dev/null
device for it12: /dev/null
device for it36: /dev/null
device for it34: /dev/null
device for it31: /dev/null
device for pr21: /dev/null
device for bs14: /dev/null
device for sa02: /dev/null
device for ap09: /dev/null
device for eh200: /dev/null
device for am36: /dev/null
device for ap30: /dev/null
device for ap37: /dev/null
device for op14: /dev/null
device for op02: /dev/null
device for eh47: /dev/null
device for iv09: /dev/null
device for ct219: /dev/null
device for ct249: /dev/null
device for eh23: /dev/null
device for eh26: /dev/null
device for eh03: /dev/null
device for eh08: /dev/null
device for eh18: /dev/null
device for eh17: /dev/null
device for eh29: /dev/null
device for eh41: /dev/null
device for eh46: /dev/null
device for am25: /dev/null
device for am83: /dev/null
device for am21: /dev/null
device for am43: /dev/null
device for am22: /dev/null
device for am72: /dev/null
device for am65: /dev/null
device for am40: /dev/null
device for am90: /dev/null
device for am28: /dev/null
device for am31: /dev/null
device for am61: /dev/null
device for am30: /dev/null
device for am12: /dev/null
device for sa264201: /dev/null
device for am02: /dev/null
device for am75: /dev/null
device for am12928: /dev/null
device for am13932: /dev/null
device for am14915: /dev/null
device for am15909: /dev/null
device for ap47: /dev/null
device for ap226249: /dev/null
device for sa262208: /dev/null
device for sa263201: /dev/null
device for sa11180: /dev/null
device for sa12123: /dev/null
device for sa15170: /dev/null
device for ap23: /dev/null
device for ap16: /dev/null
device for sa07: /dev/null
device for bs05: /dev/null
device for bs33: /dev/null
device for bs03: /dev/null
device for bsss204: /dev/null
device for bsss203: /dev/null
device for bsss202: /dev/null
device for bsss206: /dev/null
device for bsss205: /dev/null
device for bsss200: /dev/null
device for bs32: /dev/null
device for bs25: /dev/null
device for bsju250: /dev/null
device for bsju251: /dev/null
device for bsab79: /dev/null
device for bsab105: /dev/null
device for bsab80: /dev/null
device for bsab72: /dev/null
device for bscr101: /dev/null
device for bscr216: /dev/null
device for bscr201: /dev/null
device for bscu52: /dev/null
device for bscu47: /dev/null
device for bsgu81: /dev/null
device for bsto101b: /dev/null
device for bsto100: /dev/null
device for bsto15: /dev/null
device for bsto109: /dev/null
device for bsto106: /dev/null
device for bsto102: /dev/null
device for bs16: /dev/null
device for bsab77: /dev/null
device for bs19: /dev/null
device for bscr208: /dev/null
device for bscr214: /dev/null
device for bsgu90: /dev/null
device for bscr212: /dev/null
device for ct218: /dev/null
device for ec202: /dev/null
device for am23: /dev/null
device for am18: /dev/null
device for am46: /dev/null
device for op05: /dev/null
device for opcr125: /dev/null
device for op18: /dev/null
device for op19: /dev/null
device for opab120: /dev/null
device for opcu03: /dev/null
device for opgu100: /dev/null
device for opto203: /dev/null
device for ehab251: /dev/null
device for ehcu208: /dev/null
device for ehto37: /dev/null


Is that normal? I don't think so. If not... why does that happen and how can I fix it?

[Steven Sim Kok Leong]

Hi,

Then it is not a problem with your lp spooler or scheduler.

Your remote printers configuration seem to be corrupted. Use SAM to modify them to the correct entries (instead of /dev/null).

What do you see when you run /usr/sam/lbin/lpmgr?

Hope this helps. Regards.

Steven Sim Kok Leong

[Steve Steel]

Hi

/dev/null is normal

my system

scheduler is running
system default destination: b138
members of class belgo161:
belgo046
device for belgo138: /dev/null
device for belgo046: /dev/null
device for markpoint: /dev/null
remote to: mp on punto.belgium.hp.com
device for testit: /dev/null
device for printit: /dev/null
remote to: belgo138 on belgo138.belgium.hp.com
device for b138: /dev/null


Please try lpshut;lpsched -v

This will add more data to you /var/spool/lp/log file and see if it helps.

Also when a request hangs
go to /var/spool/lp/request/printername

check for a c and d file with the request number.Then check the ascii /var/spool/lp/log.


Also try
hpnpadmin -bv printer_ip when the hang happens
and post the result plus the content of /var/spool/lp/log concerning the problem


Steve Steel

[Steven Sim Kok Leong]

Hi,

Sorry, it is perfectly all right to see /dev/null.

What does /usr/sam/lbin/lpmgr output show?

Hope this helps. Regards.

Steven Sim Kok Leong

[Ruben Cardenal]

# /usr/sam/lbin/lpmgr



local name:type:enabled:accepting:location:fence:class
#

[Steven Sim Kok Leong]

Sorry, saw Steve's posting only after I tested on my system and made the correction post.

[Steven Sim Kok Leong]

Hi,

Your lpmgr output is definitely not right.

Below is my lpmgr output on a test system:

$ /usr/sam/lbin/lpmgr
RUNNING
off
lp1
local name:type:enabled:accepting:location:fence:class
lp1:remote:yes, idle:yes:lp0 on XXX.YYY.ZZZ:0: :

If your sam is working properly, then your scheduler does not appear to be running and your printer queues are not reflected as well.

Try restarting your lpsched and grep for the process.

# lpshut;lpsched
# ps -fae|grep lpsched

Check your lpsched log file as well, as Steve has indicated.

Hope this helps. Regards.

Steven Sim Kok Leong

[Steven Sim Kok Leong]

Hi,

Just a hunch. Which are the printer queues that stop serving requests ie. hung? Ping to the network print servers. Are there any packet losses?

Also,

# telnet PRINT_SERVER 515

Does this get connected? If it doesn't, your lpd on the network print server may be down.

Another hunch. Are there any differences between the network printers that work and those that doesn't (eg. firmware)?

Hope this helps. Regards.

Steven Sim Kok Leong

[Steve Steel]

Hi


Agree with conclusions shown.


But

change
printer fence priority to 1, via SAM.

see if it prints.

Also

Please try lpshut;lpsched -v

This will add more data to you /var/spool/lp/log file and see if it helps.


Then try
hpnpadmin -hpnpadmin -b -j -mall -v printer_ip when the hang happens and the same for a good printer.
and post the result plus the content of /var/spool/lp/log concerning the problem .

hpnpadmin is in the same dir as the jetdirect printer install software.

Do any other machines like PC's print directly to these printers


Steve Steel

[Ruben Cardenal]

root@tareaap2:/var/spool/lp/request/imr2# telnet 135.10.9.2 515
Trying...
Connected to 135.10.9.2.
Escape character is '^]'.

Steven, after I had to close my SecureCRT after that telnet (the connection didn't respond to Ctrl-Break), the printer seems to have gone offline, doesn't respond to pings anymore, and shows a message in its display: "80 SERVICE(01E6)" (The printer is an HP LaserJet 5si)

The problem applies to remote and network printers, some of then are HP ones, others are't. Fails ocurr randomly in all printers, this is: sometimes they print, sometimes don't. The problem affects to all queues. Also, we have two N-class servers for printing: a primary and a secundary: when primary is heavy loaded, it forwards requests to the secondary. We have tried shutting down lp services in the primary, but we get the same erros with secondary server. Jobs scheduled trough windows in all printers, work fine.

[Steve Steel]

Hi

1)TRY TURNING THE PRINTER OFF AND ON OR
using hpnpadmin -k ip_of_printer


2)Post the hpnpadmin I asked in my previous response.


3)When I telnet to my printer I get this

telnet belgo138
Trying...
Connected to belgo138.belgium.hp.com.
Escape character is '^]'.

HP JetDirect

Please type "?" for HELP, or "/" for current settings
>

The telnet is only usefull for network printers.


Conclusion

If another system like NT has locked the printer you may not get into it due to a protocol error which would cause the problems
shown.

If using jetdirect cards there is an option in hpnpadmin to reset the jetdirect card on the
printer.

Since you however talk about remote printers as well then please check for

a)Cannot fork messages in /var/adm/syslog/syslog.log

b)use kmtune -q maxuprc
to see the value of this parameter

c)If a printer hangs try to
disable printer;sleep 3;enable printer

d)All printer probl;ems can come from an overloaded network.


If you have a hanging printer type
lpstat -pprinter -oprinter

Post the result


steve Steel

[Ruben Cardenal]

root@tareaap2:/# cat /var/adm/syslog/syslog.log | grep fork
root@tareaap2:/# cat /var/adm/syslog/OLDsyslog.log | grep fork
root@tareaap2:/#

root@tareaap2:/# kmtune -q maxuprc
Parameter Value
===============================================================================
maxuprc 400
root@tareaap2:/#

By now, there are now more queued jobs. At the next, I'll post those results :)

[Steven Sim Kok Leong]

Hi,

Port 515 is the printer service port which is used by all network and remote printers to listen for print requests (print jobs).

>>> Steven, after I had to close my SecureCRT after that telnet (the connection didn't respond to Ctrl-Break), the printer seems to have gone offline, doesn't respond to pings anymore, and shows a message in its display: "80 SERVICE(01E6)" (The printer is an HP LaserJet 5si)

This shows that your lpd of your network (jetdirect) print server is unstable because a similar TCP connection is established from your remote printing client to the print server.

I would suggest that you check the firmware of your print server (JetDirect) and check if there are any pages to the lpd daemon.

The other possibility is IP address conflict. If there is any IP address conflicts, that could also result in intermittent network disconnectivity between your remote printing client and your print server. Print jobs might possibly get stuck inside the queue if that happens. Check for any possible IP address clashes.

Hope this helps. Regards.

Steven Sim Kok Leong

[Steven Sim Kok Leong]

Hi,

I was just looking around for a similar case in the ITRC forum and I found this thread which may be relevant:

http://bizforums.itrc.hp.com/cm/QuestionAnswer/1,,0x0194e7e60861d511abcd0090277a778c,00.html

In particular, look at limws1's problem.

Hope this helps. Regards.

Steven Sim Kok Leong

[Ruben Cardenal]

Hi,

No, there are no IP address conflict in this network, addressing is done very carefully.

I'm using D.06.21 version of JetDirect. I see in SAM that seems to be another lp daemon called HPDPS, but I don't know about the convenience of using it.

[Ruben Cardenal]

Hi,

It sounds interesting. We are in a switched (procurve) ethernet network, and sometimes we have little issues due to those $%??%$(=" switches. Yes, it's a possibility, but I still haven't found a reasonable explanation for a print job that was queued *two* months (until I cancelled it yesterday, of course)

Anyway: I'll do a little research about the three switches (and a Cisco 2600) involved in this lan.

[Steven Sim Kok Leong]

Hi,

So far, I observed that the confirmed symptom of your intermittent printing problem is that a telnet connection to the printer port of the JetDirect print server causes the lpd to hang and print server to suffer network disconnectivity (ping fails).

We have print servers on our network and I monitor their availability by periodically performing an nmap -sT tcp connection to port 515 of these servers. When I receive a paging alert, it indicates that either the lpd daemon is down or the print server as a whole might be down (unpingable).

If you are curious about HPDPS, you can check out this document:

http://www.docs.hp.com/hpux/onlinedocs/B2355-90678/B2355-90678.html

Extracted here for your convenience:
=====================================
HPDPS lets you make the most of your print environment by helping you to:

1) Use your existing printers, applications, and print commands.

Your users can submit jobs from their existing applications and use the same print commands they have always used by simply specifying the names of HPDPS printers as the destinations for their jobs.

2) Migrate to HPDPS print environment at your own pace.

There are no set minimum or maximum capacities in HPDPS; you can easily expand your system to include more clients, printers, servers, and queues. With this flexibility, you can start with a minimum HPDPS configuration installed on just one or two systems on a local area network (LAN). Later, you can expand your print environment as needed without requiring your users to change the way they print their jobs.

3) Receive notification of printing system events as they happen.

HPDPS provides event notification information that informs you, your users, and your printer operators when specific actions are required. For example, you can receive notification when jobs are backlogged in a queue and you can notify operators when the printers they are responsible for are out of paper. Your users can receive notification if HPDPS cannot schedule their jobs at the requested destination. The types of notification are highly configurable; you can ensure that the appropriate people are notified when significant events occur. Event messages also provide you with valuable information that can alert you to a problem within the print environment and help you isolate the cause of the problem.

4) Manage and monitor your entire print environment from anywhere within your network if you choose to run HPDPS within what is called a DCE Extended Environment. See The Two HPDPS Environments later in this chapter for more information.

When using DCE, HPDPS gives you the ability to configure and monitor your network printing system from any HPDPS client on your system. You can configure and monitor printers, servers, and queues. You can also configure default settings for the jobs your users submit to HPDPS-managed printers.

5) When you use DCE, you enable expanded security as well as single-point administration of distributed features for print management. See Managing DCE Security for HPDPS for more information.

6) Implement an industry-leading printing technology.

HPDPS is an object-oriented print environment based on the International Organization for Standardization (ISO) Document Printing Application (DPA) 10175-1 standard.
=====================================

Hope this helps. Regards.

Steven Sim Kok Leong

[Steve Steel]

Hi


For the general interest I have been reliably
informed that the HPDPS is obsolete after 11.11
as is webjetadmin.


Steve Steel