bag@tech.perpk.nt.com (Bill Gutknecht) (03/12/91)
Can anyone give me some insight concerning the .rgyloc file in /sys/node_data/etc ???? From my understanding, it points to the default registry server for the particular node. The problem is, when that server goes down, the node continues to look for it. It seems to eventually give up, but then I usually get the "Can't find Network registry server" error. Isn't it the point of registry slaves to give a node an alternative if its default server is down? Bill Gutknecht phone: (919)481-8603 Technical Computing Services email: bag@tech.perpk.nt.com Northern Telecom Inc.
pato@apollo.HP.COM (Joe Pato) (03/13/91)
In article <9103121433.AA01966@tech.perpk.nt.com>, bag@tech.perpk.nt.com (Bill Gutknecht) writes: |> |> Can anyone give me some insight concerning the .rgyloc file in /sys/node_data/etc ???? |> |> From my understanding, it points to the default registry server for the particular node. |> The problem is, when that server goes down, the node continues to look for it. It seems |> to eventually give up, but then I usually get the "Can't find Network registry server" error. |> |> Isn't it the point of registry slaves to give a node an alternative if its default server |> is down? |> |> Bill Gutknecht phone: (919)481-8603 |> Technical Computing Services email: bag@tech.perpk.nt.com |> Northern Telecom Inc. The `node_data/etc/.rgyloc file is the backing store for the shared memory block containing the cache of locations for registry replicas. This information is used by all processes accessing the registry and is updated when a replica fails. When all replicas have failed all of the entries in the cache will be marked as invalid and the next process needing to access the registry will refresh the cache. If the global location broker (glbd) is not available, there is no way to refresh the cache and the process will see a server unavailable error. The cache also notes the time of the last lookup to the glb and will not try again until at least 2 minutes have passed. You should verify that this file has an open acl. As of sr10.3 the acl on this file is forced open any time "root" tries to access the cache, but prior to sr10.3 an overzealous administrator might try to close access to this file causing poor performance (if the cache cannot be shared it will be reconstructed as a private cache for every process accessing the registry) If you only ever bind to a single registry site, I would guess that your location brokers are not connected. Use the /etc/ncs/lb_admin tool and search the global broker for the "rgy/object" object to see which replicas are listed in the location broker. If only one replica is listed, you should use the drm_admin tool to see if the glbd sites are linked together as replicas. -- Joe Pato Cooperative Computing Division Hewlett-Packard Company pato@apollo.hp.com
chen@digital.sps.mot.com (Jinfu Chen) (03/13/91)
In article <50528780.20b6d@apollo.HP.COM> pato@apollo.HP.COM (Joe Pato) writes: [useful information about .rgyloc deleted] >You should verify that this file has an open acl. As of sr10.3 the >acl on this file is forced open any time "root" tries to access the >cache, but prior to sr10.3 an overzealous administrator might try ^^^^^^^^^^^ >to close access to this file causing poor performance (if the >cache cannot be shared it will be reconstructed as a private cache >for every process accessing the registry) If this file is to supposely open, put it somewhere else, like /sys/node_data/systmp. How can a sys_admin not be panic when .rgyloc is sitting in the same directory as rc* files? -- Jinfu Chen (602)898-5338 Motorola, Inc. SPS Mesa, AZ ...uunet!motsps!digital!chen chen@digital.sps.mot.com CMS: RXFR30 at MESAVM ----------
rees@pisa.citi.umich.edu (Jim Rees) (03/13/91)
In article <5053fb08.3593b@digital.sps.mot.com>, chen@digital.sps.mot.com (Jinfu Chen) writes:
If this file is to supposely open, put it somewhere else, like
/sys/node_data/systmp. How can a sys_admin not be panic when
.rgyloc is sitting in the same directory as rc* files?
It's not a temporary file, even though it's a cache. It wants to survive
reboots.
And I don't see how having it in the same directory with the rc files makes
any difference one way or the other.system@alchemy.chem.utoronto.ca (System Admin (Mike Peterson)) (03/20/91)
In article <5056ffc4.1bc5b@pisa.citi.umich.edu> rees@citi.umich.edu (Jim Rees) writes: >It's not a temporary file, even though it's a cache. It wants to survive >reboots. > >And I don't see how having it in the same directory with the rc files makes >any difference one way or the other. I agree with this comment, but this yet again points out the necessity of a proper list of all files on a node with the proper ACLs for a truly closed (unfriendly users) environment. -- Mike Peterson, System Administrator, U/Toronto Department of Chemistry E-mail: system@alchemy.chem.utoronto.ca Tel: (416) 978-7094 Fax: (416) 978-8775