From: jrs@world.std.com (Rick Sladkey) Subject: Re: RPC: problem with librpcsvc Date: Tue, 16 Feb 1993 01:26:35 GMT
>>>>> On Mon, 15 Feb 1993 09:32:38 GMT, hank@Blimp (Hendrik G. Seliger) said:
Hank> Hi fellows! And Hi Rick Sladkey (who is the good guy who gave
Hank> us fellow linuxers RPC)
Hi Hank.
Hank> As I don't get my nfsd/mountd to start (they just can't register
Hank> their services) I though I'd give it a try and look at this.
Here are a couple of things you can check.
* Do you have "sunrpc 111/udp" and "sunrpc 111/tcp" in /usr/etc/inet/services?
* Do you have a /usr/etc/inet/protocols file with "tcp 6" and "udp 17" in it?
* Do you start /etc/portmap from one of your rc files?
* After booting can you see the portmapper running? (ps aux | grep portmap)
* Can you run rpcinfo? (rpcinfo -p)
* Do you have syslogd running and if so do you get any messages?
* Do you get "Connected to" when you run "telnet 127.0.0.1 sunrpc"?
Hank> Being a beginner to RPC I looked at the examples in the
Hank> documentation (in rpc-0.9) ... and stumbled. It seems that the
Hank> procedures rnuser, rstat, and rwall in librpcsvc places a call
Hank> to "rpc_call", which is defined nowhere, causing my little
Hank> rnuser-program not to link. If one replaces by one to "callrpc",
Hank> for which the last parameter to "rpc_call" needs to be removed
Hank> (is a null pointer anyway) the stuff just works fine. Am I doing
Hank> something wrong or do we have a version mess here or have I
Hank> found a real BUG???
Yes that is a real bug. I didn't try to link those objects and
so I didn't notice that there was a calling sequence change between
sunrpc-4.0 (what most of our RPC is based on) and tirpc-1.0 (which
is where the rpcsvc stuff came from).
Hank> Maybe this should be repaired for the next rpc-version.
Done. That's why it was called 0.9. :-)