HP-UX 11.00 print problem

[Martin Bargon]

I have a box that is about 6 years old and has been humming along like a champ. No changes have been made on the system but this weekend it stopped printing.

Jetadmin /opt/hpnpl/bin/hppi is communicating just find with the the printers (there are about 20 that are not printing right now). Sam shows the printer Idle when there is nothing in the queue, and busy when there are print jobs waiting.

Lpstat shows the jobs sitting and waiting.

I've done a lpshut, I restarted the print spooler via SAM, I've started and stopped lpsched.

I can telnet to the printers from the box, print to the printers from other systems, just this one box after it's weekly reboot didn't come back printing.

Any suggestions?

Thanks in advance

[Patrick Wallek]

Do an lpshut.

Now do a 'ps -ef' and look for any leftover lp processes. If there are any, kill them.

Then try starting the lp spooler again.

[Martin Bargon]

I tried doing a Lpshut, kill a 2 legacy LP jobs, restarted the lpsched and trie printing a job.

The job is still siting in the queue 5 minutes later, it is 25 bytes so should have gone quickly. Normally I will not see a job for this print test it goes so quickly.

lpshut followed by killing any legacy jobs followed by restarting lpsched didn't work.

[Bill Hassell]

Are the printers configured with IP addresses or by hostnames? DNS problems (bad data in the DNS server). Configuring by IP is usually better for network printers only because DNS admins seem to 'forget' about non-computer hostnames. Check on the printer names with:

grep ^PERIPH= /etc/lp/interface/*

Also chdeck that the printers can be queried with hpnpadmin:

hpnpadmin -v 12.34.56.78

and try printing with hpnpf:

hpnpf -x 12.34.56.78 -n /etc/profile

If hpnpadmin and hpnpf works OK, then the spooler has become corrupted, most likely due to permission and/or ownership changes. Check root's shell history to see if anyone tried to 'improve' security with chmod -R or chown -R.

[Steve Post]

My guess is the printers were setup with DHCP, and the /etc/hosts file has the ip address hardcoded.

Get the ip address of the printers. Then PING them. If you can ping, try to telnet to them. If you can telnet, try to log in to see the settings of the printer.

Another sillier possibility. Maybe the printer is gone. I've had it where a printer is "busted". Upon investigating, I discover it was moved to a different IP address, ........and also about 500 MILES.

The mover of the printer didn't feel like telling anybody about the move. The new office faxed the report back to the requestor.

[Martin Bargon]

The printers IP addresses are hard coded.
I can telnet to the name and to the IP address.

The printers are all defined in /etc/lp/interface/

Printers can be queried with hpnpadmin using both the IP and name.

hpnpf appears to work (I do not have anyone at the remote to check the paper).

Permissions are all read write and owned by lp.

[Bill Hassell · Accepted solution]

So the networking is fine and you just have a problem with lp. Start by issuing lpshut. Then see that spooler really is shutdown:

ps -f -u lp

There should be nothing shown. If there are processes shown, they are likely 'stuck' lpsched programs that are waiting for a print job to finish (typically, hpnpf is hung up with a printer). Use kill to get rid of all lp-owned processes. Then start the spooler again with lpsched. Normally, there will be one lpsched process whose parent is 1 (init) and several lpsched processes whose parent is the first lpsched.

If nothing starts, then the pstatus file may be corrupted. Try removing and adding a printer that you can easily check:

removequeue -q someprn
addqueue -q someprn -h 12.34.56.78

The spooler will be automatically stopped and restarted with these commands. Now print soemthing to someprn and see if it works. If not, you need to rebuild the spooler files.

Start by making a list of all the printers using lpstat -v. Copy the output to a printer using a PC. Now you can run the first attached script to create the two scripts to remove and add the printers. The two scripts created will be called:

/tmp/rmprn.sh
/tmp/addprn.sh

Make the two scripts executable, then run the first script to remove everything. Now check the directory /var/spool/lp and make sure SCHEDLOCK, pstatus, qstatus and outputq are all zero length. Then run the addprn.sh script and try one of the printers.

If this fails, you'll need to run swverify to see if all the permissions/ownerships are correct:

swverify printermgmt

At the end of the list will be an swjob command line you have to run to see the errors. Ignore errors about /usr/share/man/cat... permissions as these are normal.

[Bill Hassell]

Oops, here's the script builder.

[Bill Hassell]

Hummmm---my attacher is having problems -- must be a defective keyboard. --

[Steve Post]

Besides following Bill's advice (which is better than mine f.y.i.), check out the printer physically.

1. Walk over to it.
2. turn it off and on.
3. put paper in it.
4. run a print job to it from a different computer (windows or unix).
5. run a config page to verify the ip address of the print matches what you believe it is supposed to be.

Two weeks ago I had this problem. After the printer was power cycled, it started working again. I really didn't matter what I did on the unix side. The printer just refused to work until it was reset by removing power.

OF COURSE be careful. I have no idea what type of printer you have. For all I know, a powercycle of the printer might destroy it.