Home | Docs | Forums | Lists | Bugs | Planet | Store | GMN | Get Gentoo!

Full Text Bug Listing

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