lp command not printing

[Rex Pommier]

Hi.

I'm probably missing something obvious, but printing stopped on one of my HP-UX boxes and I can't find what happened to it. The printer is a network attached device that I can get to by other HP-UX boxes no problem, but when I try to print to it from this machine the reports go to the bit bucket. I have tried deleting and readding the printer(s) to no avail. I actually have 2 printers attached to this machine and I can't get either of them to print.

lpstat -t shows:
rrp@sur_s1p3/home/rrp $ lpstat -t
scheduler is running
no system default destination
device for is03: /dev/null
device for is02: /dev/null
is03 accepting requests since Jan 16 16:47
is02 accepting requests since Jul 14 15:55
printer is03 is idle. enabled since Jan 16 16:47
fence priority : 0
printer is02 is idle. enabled since Jul 14 15:55
fence priority : 0

The printer I am testing with is the one queued is02. I have checked in the /etc/lp/interface/is02 config file and it shows the proper PERIPH statement pointing at the printer. Any ideas on where I can go from here?

Thanks. Rex

[Jeff Schussele]

Hi Rex,

Can you successfully ping the IP of that print server?

Have you tried bouncing lp?
lpshut
lpsched

HTH,
Jeff

[Rex Pommier]

Jeff,

Yes, I can ping the printer, both via the name in DNS (which is how it is configured to HP-UX) as well as straight to the IP address. I went one step further than bouncing lp - I bounced the box - much to the chagrin of one of my DBAs. He wasn't supposed to be on the machine anyway!

[Michael Tully]

If the printer was printing and now it isn't seems that communication has been lost somehow. Perhaps it is a timing issue at the printer end. I had this happen sometimes when printer configs were not set up properly. Have a look at the I/O Timeout facility on the printer if it has one. I had problems with laser printers in our warehouses.

[Rex Pommier]

Michael, The printer is printing - just not from this box - which happens to be a partition on a superdome. The other superdome partitions can print to it no problem so apparently there is nothing wrong with the printer. Both the working and non-working partitions of the 'dome are attached to the same network switch via gigabit ethernet adapters so hardware-wise there is nothing different. That is what is making this all the more baffling.

[Eugene Klaus]

It appears you have timed out waiting for a request to send. Sometimes a disable and then re-enable will clear the printer que to send. Other times the hung print request will need to be canceled as well.

When all esle fails shutdown lpshut then lpsched.

[sreejith_4]

Hi,

Try to shut "lpsched" and run lpmove to alternative destination.

Thanks
Sreejith M

[V. Nyga]

Hi Rex,

sometimes helps:
disable printer - switch off printer - switch on printer - enable printer.

Other suggestion:
define printer as remote printer with server: one of your boxes where printer works.

Good luck
Volkmar

[RAC_1]

lpshut
lpsched -v

Noe try to print and post what the log file says?? (/var/adm/lp/log)

Anil

[Geoff Wild]

Can you:

/opt/hpnpl/bin/hpnpadmin -v is02

How did you add the printers?
If jetdirect, I would do this:

lpshut
addqueue -i 9998 -q is02 -h is02.yourdomain.com
lpsched -v

Rgds...Geoff

[Bill Hassell]

If hpnpadmin -v reports normal information (no errors), then bypass the lp subsystem with:

/opt/hpnpl/bin/hpnpf -x 12.34.56.78 -N /etc/profile

That should print a copy of the /etc/profile file. If nothing happens and no error messages show up, add -l as in:

/opt/hpnpl/bin/hpnpf -x 12.34.56.78 -N -l /tmp/jetdirect.log /etc/profile

[Rex Pommier]

First of all my apologies to those who wrote about disabling the printer and moving the reports to another one. I just went back and reread my original post and discovered that I neglected to include one very important item. The HP-UX box thinks it is printing the reports! When I disable the print queue named is02 and then try to print to it, the machine rightly complains that the queue isn't accepting reports. I then allow the queue to accept requests but leave print disabled, the reports show up in the /var/spool/lp/request/is02 directory as they should. When I then enable print, the reports vanish from the queue as if they are printing, but never actually appear on the printer. Now on to answering some of the sugggestions.

Anil, activating the logging and then printing produced the following output which appears like it should (I think).

root@sur_s1p3/>cat /var/adm/lp/log
***** LP LOG: Jul 15 11:35 *****
FIFO: Jul 15 11:38 r is02 101 root sur_s1p3 0
is02-101 root is02 Jul 15 11:38
/etc/lp/interface/model.orig/is02 d
/opt/hpnpl/bin/hpnpf -j is02-101+root -w -a1 -x surfsditil4k.cnasurety.net
CHILD: Jul 15 11:38 is02 101 0000
FIFO: Jul 15 11:38 m is02 6691
FIFO: Jul 15 11:45 n
FIFO: Jul 15 11:45 n

Geoff and Bill, The print queue within HP-UX is is02, the printer name is surfsditil4k so I did a /opt/hpnpl/bin/hpnpadmin -v surfsditil4k and following is the beginning of the output

surfsditil4k is a network printer
Printer State : printing
- connected to sur4524.cnasurety.net

sur_s1p3 is allowed access to surfsditil4k

Fail (1)

Card IP Address : surfsditil4k.cnasurety.net (172.16.6.1)
Network Mask : 255.255.0.0
Default Gateway : sur-gw-wan-eth-fsd.cnasurety.net (172.16.4.50)
Idle Timeout : 90 seconds

Uptime : 23:33:12
Connections Accepted: 49
Connections Denied : 0 (not on access list)
Connections Aborted : 0
Connections Killed : 0
Bytes Received : 5975024 (current connection)
Bytes Sent : 0 (current connection)
Total Bytes Received: 13818750 (since power-on or reconfig)
Total Bytes Sent : 4153 (since power-on or reconfig)

Control Panel : PROCESSING JOB
FROM TRAY 2
Line State : Online


The printer was added using jetdirect and if I try to add the queue it says the queue already exists so I did a removequeue -qis02 then readded it.

I did the hpnpf command to bypass the lp subsystem and it printed my file so apparently the problem is somewhere in the lp subsystem. Any further ideas will be welcome.

[Bill Hassell · Accepted solution]

Yep, sounds like a permissions problem. You might check syslog. You can see in the lp log that hpnpf is doing the actual work so it may have been given a print job that lp does not have the rights to read (typically directory permissions). Double check that no one tried to 'improve' the permissions on / /var /etc /tmp - they should be:

# ll -d / /var /etc /tmp
drwxr-xr-x 20 root root 8192 May 3 13:32 //
dr-xr-xr-x 29 bin bin 8192 Jul 15 15:16 /etc/
drwxrwxrwt 6 bin bin 8192 Jul 15 15:07 /tmp/
dr-xr-xr-x 27 bin bin 8192 May 3 11:24 /var/

(note: /tmp can also be drwxrwxrwx, the 't' is to improve user security for /tmp)

Now check the permissions that swinstall thinks should be there:

swverify PrinterMgmt

[Rex Pommier]

BINGO!!!!

Thanks, Bill. /var/tmp was recently built into a separate filesystem from /var and the permissions were set at 755 instead of 777. I set them to 777 and everything started working again. Too bad I can't give you 20 points for this one!