Hi! The fam-oss-2.6.10 ebuild makes fam unable to connect to a remote fam (and fam-oss-2.6.9 did too) . I am not talking about local_only=True, I set that back to "false", but about the actual ability to contact a remote fam (or the check to see if file X is remote or local, dunno). I downloaded fam-2.6.10 and the dnotify patch from sgi, compiled, installed by hand, and it worked fine. So the problem can be narrowed down to have to be in some of the additional things the ebuild does (in addition to applying the dnotify patch and compiling)... I think there is some glitch in the ebuild or in some of the additional patches the ebuild uses... Reproduction: Host 1: start fam Host 2: set local_only = False, start fam Host 2: go to your favourite filemanager, point it to an nfs mounted directory (host 1 mount) Host 1: change a file Host 2: didn't notice until *very* far in the future If you need any more info etc, I'll be glad to help... I'm just at a loss on where to start looking, I think the original author of all these patches would know better than me ;) Also, how's the linux kernel imon patch going ? I'd like to switch to imon because dnotify has poor performance anyways - even if it works :)
Change the line in the 2.6.10 ebuild from dnotify.patch.new to dnotify.patch and let me know if you still have problems.
re: imon it is available as an option in the gentoo-sources-2.4.20-r5 kernel which is currently stable... i'm not sure when it first was in.
ooookay... The Problem is in the KERNEL... geeeeez that was a hell of a debugging session ;) reproduction: int main(int argc, char *argv[]) { struct statvfs fs_status; /*"/mnt/ifurita-logs/syslog"*/ int rc = statvfs(argv[1], &fs_status); if (rc >= 0) { printf("OK %d\n", fs_status.f_fsid); } return 0; } and call this with a nfs mounted directory. It returns 0 (for "root file system"), which is wrong. confirmed with linux-2.4.21 and linux-2.5.75 :( gah, never handled kernel bugs, what now ?
argh, #include <sys/statvfs.h> ....
statvfs - works for xfs partitions - does not work for ext2,ext3,nfs - others untested
Did you ever try our 1.6.10 ebuild changing the dnotify.patch.new line to dnotify.patch?
yes, I did, but it did not help ... then I started debugging to find out why it still doesn't and discovered the cause, Until that is fixed, it can be worked around by #undef'ing HAVE_STATVFS in config.h (so that HAVE_STATVFS never is defined and thus never is used). (after configure) Then it works in all cases. Local. Remote. Links. :D
btw, the comment for HAVE_STATVFS in config.h reads like this: /* Define if we have statvfs. Otherwise, statfs will be used. */ That's a lie ;) statfs is never used. It just uses regular (string) pathname expansion in case statvfs is unavailable. Slower but works. I think the automake stuff could be patched to compile a test program which checks the fsid for 0, and, if it is, screams in terror, and disables statvfs... but I cannot do stuff in automake that good yet... sorry...
# # local_only makes fam ignore requests from remote clients & remote fams. # Note that this is ignored if fam is started by inetd. # # The -L command-line argument overrides this option. # local_only = true In your scenario you have set local_only = false on Host 2. It would seem that you need to put local_only = false on Host 1 though as that is the host that is getting "requests from remote clients & remote fams" Please change the setting on Host 1 and let me know if you fine things to be working properly.
I just checked... I have local_only=false on both machines
That's a lie ;) statfs is never used. It just uses regular (string) pathname expansion in case statvfs is unavailable. Slower but works. When you said that, what do you mean, slower but works? Are there possible problems with NOT using statvfs?
no, its just slower... (multiple string manipulation operations as opposed to comparing two dwords per request) I use the string-parsing (non-statvfs) version without any problems...
fam-2.6.10/TODO:- configure.in ignores the test for sys/statvfs.h on Linux because the f_fsid hrm... anyway... i have added 2.6.10-r1 to portage which changes the statvfs stuff. Please test and let me know if things work as expected. :)
yup, woriks fine now :) Thanks ! :)
More verification needs to happen before this is considered a stable ebuild but I am hoping that this change is a positive one. :)
This bug has made for very informative reading. In any case, I am just posting to say that fam-oss-2.6.10-r1 works very well for me in all cases. On my workstation with a NFS mounted /home, changes display instantaneously in Nautilus. Also, my server has courier-imap-2.0.0 running (comiled against libfam, also 2.6.10-r1 for IMAP IDLE support) and all is well. :)
