Weird problem with lpd...

QNX USERS QNX2 and QNX4
1

I swear this was working this morning…

I have lpd set up so that I can print from the network, but I have lpsrvr also running so that users on the QNX network can print from photon. In any case, this afternoon, after apparently messing with some settings, lpd now gives this error when I type lpr -P lpt1 :

lpr: lpt1: lpt1: unknown printer

The odd thng is the double listing of the printer. Everywhere I look, it says the error should just be:

lpr: : unknown printer.

My /etc/printcap file is as follows:

lpt1:
:lp=//4/dev/spool/txt:sd//4/tmp:

Lpd is running on node 1 which is connected to the network, while the printer is on node 4 because node 1 doesn’t run photon. lpsrvr is running on node 4.

Any idea what could be going on here?

2

I’m pretty much at my wits end right now. Does anyone have any clue what might be going on here? I’m really quite new to the Unix/QNX world and any help would be very much appreciated. Thanks!

3

There is simply not enough information.

Post output of sin command of both node 1 and node4.

lpd is totaly unrelated to photon so it could be setup to run node 4. It’s actually lpsrvr that might need photon if you print from it.

What is the content of /usr/spool/lp and /dev/spool

4

I think I need to reclarify…

Node 1 is the only one with TCP/IP, but it does not run photon. Therefore, lpd must go on it (so it can talk to the rest of the network) but lpsrvr cannot (because we need to print from photon).

Node 4 runs lpsrvr and photon, so it is set up with the printer in the office. Lpsrvr works fine, anyone can print from qnx/photon. Lpd is busted…

There is nothing in /usr/spool/lp.

The following items are in /dev/spool:
doc
local
ps
ps.phs
tmp
txt

I don’t have an easy way of getting to the output of sin (I am on a Windows box right now) but I can type out the running processes.

Node 1:
sys/Proc32
sys/Slib32
/bin/Fsys
/bin/Fsys.eide
idle
//1/bin/Dev32
//1/bin/Dev32.ansi
//1/bin/Dev32.ser
//1/bin/Dev32.par
//1/bin/Dev32.pty
//1/bin/Iso9660fsys
//1/bin/Fsys.floppy
//1/bin/Pipe
//1/bin/Net
//1/bin/Net.ether1000
//1/bin/Net.ether1000
//1/bin/nameloc
//1/bin/nameloc
//1/bin/cron
//1//usr/ucb/Socket
//1//usr/ucb/slinger
//1//Fsys.mbiaom3_32
//1/bin/tinit
//1//usr/bin/syslogd
//1//usr/ucb/portmap
//1//4.25/usr/ucb/nfsd
//1//usr/ucb/mountd
//1//usr/ucb/inetd
//1//usr/ucb/telnet
//1//usr/ucb/telnetd
//1/bin/ksh
//1/bin/login
//1/*/4.25/usr/ucb/lpd
//1/bin/sin

Node 4:
/boot/sys/Proc32
/boot/sys/Slib32
/bin/Fsys
/bin/Fsys.eide
idle
//4/bin/Dev32
//4/bin/Dev32.ansi
//4/bin/Dev32.ser
//4/bin/Dev32.par
//4/bin/Dev32.pty
//4/bin/Fsys.floppy
//4/bin/Pipe
//4/bin/Net
//4/bin/Net.ether82557
//4/bin/dumper
//4/*/bin/phfontpfr
//4/bin/Dosfsys
//4/bin/tinit
//4/bin/ksh
//4/bin/sin
//4/usr/bin/lpsrvr

5

TCP/IP doesnt have to run on the machie lpd is running on, but lets not get into that now :wink:

Odd I think you should have a directory for each entry in printercap

That`s ok, these are created by lpsrvr.

Make sure syslogd is running, restart lpd and look at the content of /tmp/syslog it may hold important clue.

6

This is probably why lpd is telling me that the entry in my printcap is “unknown.” Still, I can’t figure out a way for lpd to recognize the entry…

Also, the only thing that shows up in my syslog with respect to lpd is “/usr/spool/output/lpd.lock: failed to obtain lock” This seems to happen at random intervals.

7

you are missing an = sign between sd and //4/tmp for a start.

your lpsrvr should look something like

[printer name]
ta=whatever
ci=cp $(fname) $(spfile)
co=lpr -h -Pprintercapprintername $(spfile)
mx #120

and printcap

should have lp rm (if you have a remote tcp ip printer) sd (for the spool) defined… sd is usually /usr/spool whatever.

8

Yeah, the missing = was a typo…it is actually there.

Lpsrvr works fine. I can use lp and print from any of the nodes. Only lpd seems to be screwy. The printer is not a remote printer, it is hooked up to node 4, although I would eventually like to be able to print to it from remote computers, so I don’t need the rm.