Path: utzoo!utgpu!cunews!bnrgate!brchh104!brchs1!bnr.ca!rice.edu!sun-spots-request
From: markl@hpbbi4.HP.COM (#Mark Lufkin)
Newsgroups: comp.sys.sun
Subject: Re: rpc registration and how to tell of a cnode death ?
Keywords: No Digest Subjects in Unmoderated Mode
Message-ID: <3177@brchh104.bnr.ca>
Date: 4 Jun 91 18:40:00 GMT
Sender: news@brchh104.bnr.ca
Organization: Sunspots, Psuedo-Unmoderated
Lines: 56
Approved: sun-spots@rice.edu
X-Original-Date:    Wed, 16 May 1990 16:41:48 GMT

> Q-1) I'm trying to build amd/amq (an automounter daemon), it builds ok, and 
> to run ok. (I can remount fs's with it with out any ptoblems).  But amq talks
> to amd via rpc port number 300019.  The port is supposedly registered, it's
> in the /etc/rpc file correctly.  But whenever I invoke amq, it comes beck with
> rpc not registered (or something to that effect).  And sure enough, when I 
> run /usr/etc/rpcifo -p the port isn't registerd. I thought all I had to do was
>  put a line in /etc/rpc to register the port.  Does anyone have an idea why 
> rpc isn't seeing the new entry in the file ? (I've tried rebooting and nothing
> changed)

	I am going to be completely useless at answering your question and
	(hopefully) make a suggestion that may help you. First, sorry I don't
	really know enough about SUN RPC to be able to answer a techncial
	question on it. What I would like to suggest is the use of NCS 
	(Networking Computing System). This is available on HP platforms
	and is fully supported. It has also been chosen as the RPC for use
	in the OSF Distributed Computing Environment (this was announced
	yesterday and includes a lot more than RPC). Note that SUN RPC was
	also a contender for use but was not picked for a variety of technical
	reasons. Enough of my little speech (I guess I am entitled to it as I
	support this stuff).
> 
> Q-2) If your on a cluster server, is there a way you can tell when/how a cnode
> dies (loses contact with the server) ?  This would seem to be so unusual of a 
> request.

	I guess you are talking about HPUX diskless here (also part of OSF/DCE
	incidently). The easiest is that the client will panic and give you a
	message saying why it panic'ed. Diskless nodes don't core dump (unless
	they have local swap) so you will not be able to get more information
	on why the crash occurred. If you are only interested in why / how it
	loses contact with the server this is more of a networking problem. You
	would then need a network manager / analyser of some sort. As far as
	server is concerned it simply that it can no longer communicate with
	the client.

> 	
> 	Any reply would be appreciated, Thanks,
> 	greg
> 				Greg Sylvain
> 				Academic Computing Services
> 				Systems Programmer
> 			
> 	UUCP:           	...!{uunet}!umbc5!greg
> 	Internet (Arpa) :	greg@umbc5.umbc.edu
>  	BITNET :		GREGS@UMBC
> ----------

Mark Lufkin
WG-EMC
OS Technical Support
HP GmbH, Boeblingen

These are obviously all my own opinions and don't necessarily reflect
those of HP etc. etc.