SCO 5.0.7 - Problems with external print servers and remote printing

[CarrahaG]

Hello

Over the weekend we migrated from an old server running SCO OpenServer 5.0.7 to a new server running the same SCO OpenServer 5.0.7.

Since then we have been having problems with remote printing. The print jobs do not print and they remain in the queue.


We have several printers set up as follows:

SCO OS <------> External D-Link DP-101p+ <-------> Okidata ML 320

The print server is configured as follows:
IP Address -> 192.168.10.163
Server Name -> speedy
Port name -> speedyptr


We did the following when setting up remote printing:

1. run "mkdev rlp".
We did not install any printers. We only started the remote printing daemon.

2. We inserted the following line in the "/etc/hosts" file.

192.168.10.163 speedy speedy.jolley.local


3. We ran "rlpconf". We used the following settings:

printer name -> speedyptr
remote printer or local printer (r/l) -> r
host name -> speedy
Extended RLP protocol -> n
System default -> n


4.We then issued the following commands:

/usr/lib/lpshut
/usr/lib/lpsched
enable speedyptr
accept speedyptr

5. We then checked the entry in the "/etc/printcap" file. It was as follows:

# Remote Line Printer (BSD format)
speedyptr:\
:lp=:rm=speedy:rp=speedyptr:sd=/usr/spool/lpd/speedyptr:mx#0:


6. We then ran the command "lpstat -t". We got the following:

speedyptr accepting requests since "...."
speedyptr:
queuing is enabled
Printer Status: On line


7. We then sent a print job as follows "lp -d speedyptr /.profile"

8. We then ran the command "lpstat -t" again. We got the following:

speedyptr accepting requests since "...."
printer speedyptr waiting for auto-retry. available.
stopped with printer fault.

The print job entry remains in the queue:

speedyptr-1462


9. We then try to cancel the print job and get the emssage:

UX:cancel: WARNING: Request "speedyptr-1462" does not exist.

10. We go to the directory "/usr/spool/lp/requests" and we see the file "1462-0".


Can anyone tell us what step we are missing? The same printers and print servers were working with the old server hardware. the only thing that changed was the server hardware.

Looking forward to any advice.


Regards,
Georges

 

[PHV]

The remote printer's request should be in the /var/spool/lpd/speedyptr directory, not in /var/spool/lp/requests !
Don't you have (or had) a *local* printer named speedyptr ?

Hope This Helps, PH.
FAQ219-2884
FAQ181-2886

 

[CarrahaG]

Hello

No we don't.

When we run "scoadmin printer", we see the printer "speedyptr" defined as type "R". Also, we navigated to "/var/spool/lpd/speedyptr" and that directory is empty.

Regards,
Georges

 

[PHV]

What is the output of the following command ?

ps -fe | grep [l]pd

Hope This Helps, PH.
FAQ219-2884
FAQ181-2886

 

[CarrahaG]

Hello,

I am assuming that the character in between the square brackets is the number one.

ps -fe | grep [l]pd

If so we ran the command and it gave the result "No match."

Regards,
Georges

 

[PHV]

character in between the square brackets is the number one
No, lowercase L

 

[CarrahaG]

Hello,

We ran the command with the lowercase letter L in between the square brackets as follows:

ps -fe | grep [l]pd

It still gave the same result "No match."

Regards,
Georges

 

[PHV]

Did you reboot the server since the mkdev rlp ?
If the answer is no the type the following as root:

/usr/lib/lpd &

Hope This Helps, PH.
FAQ219-2884
FAQ181-2886

 

[CarrahaG]

Hello

We ran the command "/usr/lib/lpd &". However, no change.

After that, we ran the command "ps -e | more" to see if the lpd process was in memory. We do see the process in memory.

After that, we also ran the earlier command "ps -fe | grep [l]pd". It still gave the same result "No match."

Regards,
Georges

 

[PHV]

Which shell are you using ?
I gave you Bourne (or Korn) shell commands.
Hopefully you don't use csh, do you ?

Hope This Helps, PH.
FAQ219-2884
FAQ181-2886

 

[CarrahaG]

Hi

I am using the csh shell. I can try this under the Bourne shell. I will need to check this out.

Regards,
Georges

 

[CarrahaG]

Hi

I did the whole process over again using the Bourne shell.

I ran the command "/usr/lib/lpd &". I then ran the command "ps -fe | grep [l]pd" and it returns as follows:

root 3759 1 0 14:42:32 ? 00:00:00 /usr/lib/lpd

We then sent the command "lp -dspeedyptr /.profile". The job is still stuck in the queue.

Regards,
Georges

 

[piperent]

So, what ever happened here? Did we ever get the print jobs to print? Is there some special little trick that we are all oblivious to that makes all these problems go away? Was it a hardware issue with the new server? Or, is it still an issue pending a resolution?

Thanks,
JP

 

[mike114327]

Sorry for my late response to this one.....

One thing to remember is that the time you run the mkdev rlp is important. If you are like most of us, you loaded
all the patches before starting to configure the system. One
of the add-ons thrown in is CUPS. IF CUPS is installed before
the mkdev rpl command we have found lots of trouble.

We tried to stop using remote printing and setup netcat
scripts to interface with the print spoolers. This took care
of all the lpstat hang issues that are common with remote
printers. Also tried to not install the CUPS when ever
possible. Some people love it. I found good old lp and
lpadmin a lot easer to use and maintain in our small sites.

One other thing that can cause grief, found in RH 5, is
that if the hosts file does not have 127.0.0.1 localhost in
it,there can be lots of printing issues with cups.

Just a couple of thoughts.

Mike