Printer is down, but isn't down...?

[Managed Services]

Hi all

I'm having an issue with a network printer on a remote site with the following symptoms:
- I am sending print-jobs to the printer but nothing prints.
- Users who are local to the remote printer can print to it using Windows software, but are also unable to print to it via Unix.
- Printer is reported as being down in lpstat, as shown below, however our counter-part IT department say the printer is working:
printer queue for RSP8HP4050_1

Windows LPD Server
Printer \\xxx.216.6.203\RSP8HP4050-1

Owner Status Jobname Job-Id Size Pages Priority
----------------------------------------------------------------------------
mentor01: Warning: RSP8HP4050_1 is down

mentor01: sending to fileserver2.intra.xxxxxxxxx.co.uk

I have drawn a blank and my question is, is there anything I can do to figure out whether there is something wrong with the Unix side, or their side?

Please note that I only have administrative access to the Unix side.

thanks in advance.

[john kingsley]

You mentioned that the print is at a remote site. Have you tried connecting to the printer either by telnet or web browser? Verify that you have the correct IP or hostname in /etc/lp/interface/RSP8HP4050_1 file. If you reference the hostname in this file, verify that your system can resolv it. Are you using jetadmin tools? Have you ever been able to print to the printer from the remote UNIX systems?

[Managed Services]

Hi, thanks for your reply.

I have attempted to telnet to the IP and whilst it does connect, it does not give me a login screen.
The printer has worked for several years and the file /etc/lp/interface/RSP8HP4050_1 has remained unchnaged since 2001.

I'm not actually the admin for the printer itself, just the Unix server, which sends print-jobs to several other printers, all of which are working fine (apart from this one) and they are all directed through a file & print server @ fileserver2.intra.xxxxxxxxx.co.uk. The print server is administered by a counter-part IT department on the remote site. Personally, I can't see anything wrong with the Unix server, but I just need to know if there is something I have missed, before I tell them it's their side which is at fault.

[Managed Services]

Resolved!

The remote print server needed to have it's print queue reset. Once that was done, I re-enabled the printer here and printing resumed.

Thank you for your help!

[Steve Post]

This is a very normal thing for me. Guy at remote site says printer is down, but windows printer is ok.
I ask for the printer name: it's "5", no it's "windows printer xyz", no it "billy" (billy being the name of a postit note next to the printer). So I can't get the name.

Sigh. I guess the actual name is: "the one that stopped working".

I then log into the UNIX box and run "lpstat -o". The printer is really "rlp_curwood". I know it. It's the only printer with 30 jobs stuck on it.

Solution?
reject rlp_curwood
disable rlp_curwood
enable rlp_curwood
accept rlp_curwood

Cause?
Person shut of the printer, or the network connection was disrupted. At that time, a job was being sent to the printer. Because UNIX saw the printer was having problems, it disabled the printer. UNIX wants to save the print job instead of throwing to a DEAD printer.