lp question - lp message-ready and waiting - Don't get the same message on two servers

[Jack C. Mahaffey]

I've got a primary and backup HP9000 server that have printers defined.

My production server returns the message similar to the following:
chl002h: Printer173p1: ready and waiting.

The failover server returns the message:
no entries

I've found the description for the "ready and waiting message" in the forum and it relates to the rlp command.

Description of the messages is as follows:
"The command rlp command is ready to send another print request."

Why don't I get the "ready and waiting" message on the failover server?

Thanks in advance...

Jack..

[Patrick Wallek]

What command did you use? How are the printers set up on each machine? Are they set up differently? Is one machine set up with remote printers and the other using jet-direct?

[Michael Steele_2]

Remote printers use the rlpdaemon in /etc/inetd.conf. This line should not be commented out on the server where the printer is attached:

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

To obtain the status of a remote printer use the rlpstat command:

rlpstat -d printer

http://docs.hp.com/cgi-bin/fsearch/framedisplay?top=/hpux/onlinedocs/B2355-90681/B2355-90681_top.html&con=/hpux/onlinedocs/B2355-90681/00/03/308-con.html&toc=/hpux/onlinedocs/B2355-90681/00/03/308-toc.html&searchterms=rlpstat&queryid=20030404-183052

Here is the procedure for setting up a remote printer:

From server side where printer is attached:

1a) ps -ef | grep rlp (* rlpdaemon running? *)
2) Kill rlpdaemon
3) vi /etc/inetd.conf (* uncomment out the line indicated above *)
4) inietd -c (* restart *)
5) entries for remote host in /etc/hosts? (* must be able to ping both way *)
6) verify printer works for local print jobs

From client side:

1) lpstat -t (* printer exists? *)
2) lpadmin -x printer (* delete is does *)
3) lpshut

4) lpadmin -p local_printer ???mrmodel -v/dev/null -ocmrcmode1 -osmrsmode1 -orm -orp

5)enable local_lp_name
6)accept local_lp_name
7)lpsched (* restart *)

http://docs.hp.com/cgi-bin/fsearch/framedisplay?top=/hpux/onlinedocs/B2355-90681/B2355-90681_top.html&con=/hpux/onlinedocs/B2355-90681/00/01/165-con.html&toc=/hpux/onlinedocs/B2355-90681/00/01/165-toc.html&searchterms=remote%7cprinter%7clpadmin&queryid=20030404-184335

[Jack C. Mahaffey]

Patrick, here's the answers to your questions:

1) What command did you use? lpstat
2) How are the printers set up on each machine? Printers are actually cloned using lpmgr. One of the servers acts as failover.
3)Are they set up differently? No
4) Is one machine set up with remote printers and the other using jet-direct? Base configuration is via using lpmgr utility to transfer printers.

Sorry for late response, I forgot where I posted the message...
jack...

[Geoff Wild]

Just a thought - is DNS setup differently? IE - does HOST A have some printers in /etc/hosts and the other HOST doesn't?

Rgds...Geoff

[Geoff Wild]

BTW - you mention failover. Are you running MC Service Guard? That's what I do and have a "Printing" package - if the spooler (or hardware) dies, then the package fails over to the other node - this works great - but you can't do lpstat on both servers - as the files are on shared disk. If you want some help on this, I can provide some info on how I did it.

Rgds...Geoff

[Jack C. Mahaffey]

Not running Service Guard but both servers share a disk array with only one of the servers activating the disk array.
We clone the passwd, group, host, inetd.conf, services and some other local system files to both servers before failing over. Prior to failing over, we bring the production sever to init level, which does the umounts and volume group deactivations. The Failover server is then brought up to init level 4.

The printers from what I can see are the same on both servers. I use the lpmgr tool to replicate the printers. Hosts, services, inetd.conf, and other files are synced.

I'm just confused why one server would give the message ready and waiting while the other server shows no entries for these particular printers.

jack...

[Geoff Wild]

Try running this command on both servers (to a remote printer):

rlpstat -dqueue

where queue is the printer name.

When I do a lpstat on my servers, even to remote printers, I only get "no entries"

Rgds...Geoff

[Michael Steele_2]

Jack:

Locate rlpdaemon. This will indicate the server. Its absence will indicate the client.

Remote and cloned printers are sometimes used interchangeably.

Also refer the /etc/lp/interface/printer_name. Here is the system script used to define each printer. You should be able to do a stare and compare from each system to check for differences. Or just use the diff command.

[S.K. Chan]

I'm curious to find out if the pstatus and qstatus files (in /var/spool/lp) are the same on both servers ? well, if either one of the file is corrupted that may explained why you're seeing inconsistent printer queue status. It does not hurt to try to recover these files and see if it helps. There may be some previous threads that you can search that talks about how to do this.

[Jack C. Mahaffey]

Here's the output from the rlpstat command on the servers:

Production Server:
[358]root@chl002h:/ # rlpstat -dPrinter174p1

printer queue for Printer174p1

chl002h: Printer174p1: ready and waiting
[359]root@chl002h:/ #


Failover Server:
[8194]root@chl001h:/home/root # rlpstat -dPrinter174p1

printer queue for Printer174p1

[8195]root@chl001h:/home/root #


The process rlpdaemon is not running in the background on either server.

[Jack C. Mahaffey]

I compared the /etc/lp/interface/ files on both systems and they are the same.

[Jack C. Mahaffey]

Both the pstatus and qstatus files are inconsistent between the servers.

Wonder if it would hurt to copy the qstatus and pstatus files on the Primary to the Failover server.


I'll look for info in recovering these files.

Thanks...
jack...

[Michael Steele_2]

The only other comparisons to make then are in /var/spool/lp. For example, 'outputq' is the print job queue specific to each printer.

Also, if you're worried about corruption, and I haven't seen a complaint yet, it???s more of an informational posting that you've created, if you're worried about corruption then you can remove and remake the printers.

[Jack C. Mahaffey]

Well, I figured out where the message is coming from. Here's what I found....

The production server has two files in the /var/spool/lp/request/ directory. They include:

.remotesending
.sendingstatus

The .sending status file contains the text of the message "Printer174p1: ready and waiting"


The lpmgr -R option apparently does not create these files.

Anyone understand when or how these files get created.

Here's the ll output:
380]root@chl002h:/var/spool/lp/request # ll Printer174p1
total 2
-rw-r--r-- 1 lp lp 0 Mar 5 11:32 .remotesending
-rw-r--r-- 1 root lp 32 Apr 9 12:57 .sendingstatus
[381]root@chl002h:/var/spool/lp/request #


Jack...

[S.K. Chan · Accepted solution]

Those files get created or updated everytime you run the lp command. I noticed the timestamp and of both files are not the same. Essential they should be the same everytime and lp request is processed. This could be the problem here. Why don't you do this. Remove both files and send a test print (ie let lp daemon recreate those files for you). Hope that will help.

[Jack C. Mahaffey]

Then it must be okay for the files to not exist at this point on the failover server because nothing has been printed to these files yet. I feel much better now. I thought they needed to exist on both servers.


Thanks all...