Michael Wardle wrote:

On Tue, 2003-04-15 at 10:13, Ken Tanzer wrote:

I took the "bind" entry out as suggested, and it doesn't seem to help. I don't think that setting should matter anyway, as we're not trying to use FAM on a non-local machine.

It will matter on the server, I think. I can't see how it would matter on the client, but you might like to try it there as well, just in case.

I took the bind entry out on both sides, and still no luck.

But additionally, I'm either missing something (probably obvious :)), or not conveying something clearly.  Per the FAM man page,

"If asked to monitor files on an NFS mounted filesystem, fam tries to use fam on the NFS server to monitor  files.  If fam cannot contact a remote fam, it polls the files instead."

It seems like the polling is not working.  Given that I did have the bind=127.0.0.1 on the NFS server ("Machine B"), FAM on machine A definitely would have been unable to contact it, and therefore should have resorted to polling.  But it doesn't.

The only thing running on a non-local machine is the NFS server. Here's a bad diagram: MACHINE A FAM Client Running FAM Server Running Watching /mnt/nfs/somedir-->NFS---->/somedir/somefile NFS Server MACHINE B From Machine A, "touch /mnt/nfs/somedir/somefile" is picked up by FAM. When you do "touch /somedir/somefile" from Machine B, nothing happens. I've been wondering if this is the same problem described in FAM bug #166 ("Pollster broken by DNotify patch", http://oss.sgi.com/bugzilla/show_bug.cgi?id=166).

This should only apply if your kernel does not provide the DNotify API. Red Hat has only used the DNotify patch on versions of their distributions using Linux kernel 2.4 and higher, so provided you are also using a 2.4 or higher kernel, I'm not sure that this bug affects you.

RedHat 8.0 does have a 2.4 kernel.  It also comes with  fam 2.6.8, but it definitely seems to have the DNotify patch.  Here's a snippet from the SPEC file of the source RPM:

URL: http://oss.sgi.com/projects/fam/
Source: fam-%{version}.tar.gz
Source2: sgi_fam.xinetd
-->Patch1: fam-2.6.8-dnotify.patch<--
Patch2: fam_build.patch
Patch7: fam-2.6.7-cleanup.patch
Patch8: fam-2.6.7-gcc31.patch

Maybe it would be useful for me to write another test script that tests whether a local famd can connect to -- and get updates from -- a remote famd.

Thanks for mentioning this problem to me. I'm glad you're investigating the possible causes, but I don't think we've yet hit it on the head. Some other things I'd suggest trying are: - running famd with the debug flag (-d) on the server and the client - ensuring the sgi_fam service is registered on the server using portmap - ensuring fam is not blocked by firewalling or tcp wrappers - ensuring the contents of /etc/mtab and /etc/exports are sane - monitoring network traffic using tcpdump I haven't used the NFS functionality in FAM for a while now (partly because all my Linux servers are running Red Hat which disables FAM networking out of the box). I'll have a look at it myself when time permits, but this isn't likely to be soon. Thanks and good luck

Thanks for these suggestions.  I will try to go through them soon, probably tomorrow.  Do you think any of them would be relevant to getting polling working, or are they all network-focused?  (If I got either one working, I'd be happy.  I just tried zeroing in on polling 'cause it seemed like it would be simpler to isolate the problem!).