fam
[Top] [All Lists]

Re: FAM not notifying of non-local changes on NFS files

To: fam@xxxxxxxxxxx
Subject: Re: FAM not notifying of non-local changes on NFS files
From: Ken Tanzer <ktanzer@xxxxxxxx>
Date: Mon, 14 Apr 2003 18:14:19 -0700
In-reply-to: <1050366882.15710.8.camel@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>
References: <3E96F39E.1090105@xxxxxxxx> <1050276396.2229.6.camel@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <3E9B4EB8.1050107@xxxxxxxx> <1050366882.15710.8.camel@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>
Sender: fam-bounce@xxxxxxxxxxx
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030312


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!).

<Prev in Thread] Current Thread [Next in Thread>