Non-Functioning Network Printing

[Paul J. Ledbetter, II]

I have a number of HP Jet-Direct-connected network printers defined as network printers through SAM/hppi. They show up as enabled, lpsched is running. When I try to print using lp -d, the print job is generated, but goes nowhere. However, I can go directly into hppi and send test pages to those same printers. What's going on?

[A. Clay Stephenson]

This sounds like a classic hung lp subsystem.

1) lpshut
2) cd /var/spool/lp
3) ls SCHEDLOCK *FIFO; if any of these are present remove them.
4) ps -ef | grep lpsched
If any "stray" lpsched's are running, kill 'em dead using kill PID (kill -9 PID, if you must).
5) lpsched

You should be printing now.

[A. Clay Stephenson]

I should also add that if the above procedure doesn't fix you, examine /var/spool/lp/log for clues.

[A. Clay Stephenson]

Since you mention that these are Network printers, you should add one more step.

Do a ps -ef | grep hpnpf
just before the lpsched command. If there are any hung hpnpf's kill them. However, because the is affecting multliple printers, it still is more likely that you hava a hung lpsched.

[Floyd Curtis]

try lpshut
ps -ef | grep lp => to be sure that it stopped.
lpsched -v => to be sure logging is enabled.
try another print job, then check /var/adm/lp/log for errors.

Since you said you can send test prints, and these are network printers, be sure you can ping the printer by both name and ip ( I believe that the test print may use ip...) Had a similar instance that was caused by limited read permissions on /etc/hosts file. chmod 444 fixed it.

good luck
fwc

[Paul J. Ledbetter, II]

Nope, no hung lpsched. This problem seems to only affect networked (JetDirect or otherwise) printers. Remote printers print. I did, however, find the following entry in the /var/spool/lp/log:
Start: 89_1-62 Wed Mar 24 07:21:01 EST 2004
sed: Cannot find or open file /var/spool/lp/request/89_1/cA0062boss_hog.
grep: can't open /var/spool/lp/request/89_1/cA0062boss_hog


There is no such file in that directory. So now what?

[Paul J. Ledbetter, II]

Floyd, Clay, please bear with me while I get used to the points system. I am new at this for now. Your comments about /var/spool/lp/log gave me a lead, but I'm still not sure where it would lead me. What would cause the system to know about a file in /var/spool/lp/request, but not have the file there? It seems as if the system attempted to write the files there but somehow the process didn't complete, but logged it as completed anyway. What should the ownership/permissions be for the files and subdirectories in /var/spool/lp anyway? Am I safe with lp:bin for ownership? I'm noticing a lot of lp:18 ownerships. Is that a problem?

[RAC_1]

The file ownership should be lp:bin for /var/spool/lp. Also the /var/adm/lp/log complains about sed and grep stuff. Check the interface files for these printers in /etc/lp/ineterface directory and check the interface scripts for the printers.

Anil

[Paul J. Ledbetter, II]

RAC: Should the file ownerships be lp:bin for the interface directory as well?

[Bill Hassell]

Anytime there is a number rather than a name (owner or group), it means that whatever the number pointed to, it has been removed. 18 is not one of the standard group numbers so there are a couple of possibilities:

Someone typed the command:

chgrp 18

If there are lots of files with 18, or worse, lots of directories and subdirectories in the spooling system (/etc/lp /var/spool/lp and /usr/lib/lp) then some has used the dreaded -R command with chgrp (and possibly chown and/or chmod). You can use swverify to list all the mistakes:

swverify HPNPL.HPNPL-RUN PrinterMgmt.LP-SPOOL

This will take a while but the result is a list of problems with the installed software. The results are logged and you can read the log using swjob (the actual command line is listed in the swverify run). Once you fix the problems (except the permissions for /usr/local which should be 755 but swverify is instructed to look for 777...that's a bug in the PrinterMgmt package definitions).

I've seen the disappering print jobs in the past and they are almost always permission/ownership issues. Note that once you fix the problems, you may still have to delete the printer and re-add it (addqueue is a good tool to save time) to enable the printer. The JetAdmin program hpnpf is a great way to test the networking and bypass the spooler completely.

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

[Paul J. Ledbetter, II]

Bill,
I have a lot of errors regarding "mtime" is that something I can fix? For example,

"File "/usr/lib/milli.a" should have mtime "1013523584" but the
actual mtime is "1079924718".
"

[Bill Hassell]

mtime indicates modification time. Normally this happens because of patches but patches are supposed to fix the indexes. If there aren't any errors regarding ownership or permissions and hpnpf prints just fine, you'll probably have to use swinstall to re-install PrinterMgmt.LP-SPOOL and then the JetDirect software--use the -x reinstall=true to re-run the install. The spooler files are on the Core/Install CD, follow that with the latest lp patches and then add HPPI (JetDIrect) software. The current spooler definitions should not be affected but I would delete and re-add (removequeue, addqueue) the printer(s) anyways.

[Paul J. Ledbetter, II]

I'm reinstalling patches and PrinterMgmt.LP-SPOOL. I had a disasterous IGNITE restore from another, supposedly identical system that I think precipitated all of this. I will let you know what happened.

[Bill Hassell]

Most Ignite restore problems are related to options. The default options will create a minimal system with a huge number of missing files and directories. If you didn't use the -x inc_entire=vg00, then the resultant system not be much more than a cold install from the CD.

[Paul J. Ledbetter, II]

With help from HP, I was able to get my network printing problem by correcting permissions and ownerships. The following are the changes I had to make:

chmod 555 /var
chmod 555 /var/spool
chmod 644 /var/spool/lp/default
chmod 755 /etc/lp/cinterface
chmod 755 /etc/lp/class
chmod 755 /etc/lp/info
chmod 755 /etc/lp/interface
chmod 755 /etc/lp/member
chmod 755 /etc/lp/sinterface
chmod 755 /var/spool/lp
chmod 755 /var/spool/lp/receive
chmod 755 /var/spool/lp/request
chgrp bin /var/spool
chgrp bin /var/spool/lp/pstatus
chgrp bin /var/spool/lp/qstatus
chgrp lp /etc/lp/cinterface
chgrp lp /etc/lp/interface
chgrp lp /etc/lp/member
chgrp lp /etc/lp/sinterface
chgrp lp /var/adm/lp/log
chgrp lp /var/spool/lp/default
chgrp lp /var/spool/lp/outputq
chgrp lp /var/spool/lp/request
chgrp lp /var/spool/lp/seqfile
chown bin /var/spool
chown lp /opt/hpnpl/tmp


Suddenly, I had network printing once again! I still have other problems, but at least this one is solved. Thanks to all who tried to help!

[A. Clay Stephenson]

It would have really helped had you mentioned "Ignite" or restore initially. That would have turned on instant lightbulbs. Lp is extremely sensitive to owner/group as well as making sure that setuid bits are preserved.