Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!mips!sgi!shinobu!odin!dave From: dave@sgi.com (dave "who can do? ratmandu!" ratcliffe) Newsgroups: comp.sys.sgi Subject: Re: workspace Keywords: workspace, file access monitor (fam) Message-ID: <1990Sep25.172535.14621@odin.corp.sgi.com> Date: 25 Sep 90 17:25:35 GMT References: <503@texhrc.UUCP> Sender: news@odin.corp.sgi.com (Net News) Organization: Silicon Graphics, Inc., Mountain View, CA Lines: 78 In article <503@texhrc.UUCP> mjz@texhrc.UUCP (Michael Zeitlin) writes: > > ever since we upgraded to 3.3 (~a few weeks ago) workspace > does not work....I geet: > > iris%Can't connect with File Access Monitor (fam) > > i don't really use workspace ...but like to brag to my Mac colleagues > that the iris is just as friendly as the Mac's! > > i wanted to demonstrate workspace, but to no avail.... > is there some initialization files that i should look for or > something? a while back but, it seems no one else has responded. to the best of my knowledge there is only one reason that has come in via calls to HotLineLan' where one will encounter the ubiquitous "can't connect to File Access Monitor" error message. below follows the a "write-up" describing the approach that has always addressed/solved this up to now: ****************************** --- ******************************** cust was finding one of 2 problems occuring when, on their >= 3.2 OS 4D machine, they tried to either fire up ypbind AFTER workspace was already running, OR trying to invoke workspace AFTER ypbind was already running. 1. if workspace is already running and invokes ypbind the system hangs solid 2. if ypbind is already running and they try to invoke workspace they get the error "can't connect with file access monitor". The problem was that their YP server machine was not a >= 3.2 IRIX machine (in this case it wasn't even an IRIS--it was a SUN). below are two ultimate knowledge pieces from sgi-internal know-alls: ----------------------------------------------------------- Fact: If a site is running >= 3.2 software, its YP master machine must also be running the >= 3.2 version of /etc/rpc, which has the services needed for file system monitoring contained within it. ----------------------------------------------------------- ALL this yp and workspace stuff : Two problems have been around : 1 - If the yp server is not running >= 3.2, the /etc/rpc database for everyone who is using yp will not have sgi_fam and sgi_toolkitbusd in it. To fix this, the following lines should be added to /etc/rpc on the server: sgi_toolkitbus 391001 sgi_fam 391002 Then, you should ( on the server ) cd /usr/etc/yp; make rpc 2 - Some people on larger networks have had trouble with autoworkspace. Basically, if the network is large and slow enough, the yp server is not resolved by the time the system tries to start the workspace, and so the workspace fails to start ( since it can't connect to fam, since yp won't tell it how to....) A second or so later, if you try to start the workspace from the system menu, it starts up fine (since yp has by then gotten it's act together...) -- daveus rattus yer friendly neighborhood ratman KOYAANISQATSI ko.yan.nis.qatsi (from the Hopi Language) n. 1. crazy life. 2. life in turmoil. 3. life out of balance. 4. life disintegrating. 5. a state of life that calls for another way of living.