[Gluster-devel] glfsheal test failures

[Jeff Darcy]

> What exactly is the failure that you are observing (and on what .t file)?

The one that always fails for me is basic/self-heald.t:

}}} /usr/sbin/glfsheal: error while loading shared libraries: afr.so: cannot open shared object file: No such file or directory
}}} (repeats a few dozen times)

> Currently the only way glfsheal gets invoked is when you run 'gluster vol
> heal <volname> info`,
> which just calls the glfsheal binary with <volname> as the argument.
> The tests which do so  pass on my system (for eg
> tests/bugs//bug-861015-log.t) and I haven't
> explicitly added anything to  LD_LIBRARY_PATH.
> 
> Running glfsheal does seem to locate afr.so:
> ----------------------
> [root at ravi4 ~]# strace /usr/local/sbin/glfsheal 2>&1 |grep afr.so -A6
> open("/usr/local/lib/afr.so", O_RDONLY) = -1 ENOENT (No such file or
> directory)
> open("/usr/local/lib/glusterfs/3.7dev/xlator/cluster/afr.so", O_RDONLY) = 3
> read(3,
> "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0000\324\0\0\0\0\0\0"..., 832)
> = 832
> fstat(3, {st_mode=S_IFREG|0755, st_size=1201900, ...}) = 0
> mmap(NULL, 2580288, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) =
> 0x7f9f51273000
> mprotect(0x7f9f512e3000, 2097152, PROT_NONE) = 0
> mmap(0x7f9f514e3000, 24576, PROT_READ|PROT_WRITE,
> MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x70000) = 0x7f9f514e3000
> close(3)  

Even easier:

}}} ldd /usr/sbin/glfsheal
}}} 	linux-vdso.so.1 =>  (0x00007fffb9709000)
}}} 	libglusterfs.so.0 => /lib64/libglusterfs.so.0 (0x00007ff1330e8000)
}}} 	libreadline.so.6 => /lib64/libreadline.so.6 (0x00007ff132ea1000)
}}} 	libncurses.so.5 => /lib64/libncurses.so.5 (0x00007ff132c7a000)
}}} 	libtinfo.so.5 => /lib64/libtinfo.so.5 (0x00007ff132a50000)
}}} 	libgfxdr.so.0 => /lib64/libgfxdr.so.0 (0x00007ff132838000)
}}} 	libgfrpc.so.0 => /lib64/libgfrpc.so.0 (0x00007ff13261c000)
}}} 	libgfapi.so.0 => /lib64/libgfapi.so.0 (0x00007ff132402000)
}}} 	afr.so => not found
}}} 	libxml2.so.2 => /lib64/libxml2.so.2 (0x00007ff132098000)

Running ldconfig doesn't fix it.  This is a Fedora 20 system, BTW.
Explicitly linking a translator's .so from the makefile is the wrong
thing to do anyway.  It's not how any of our daemons load them, and
I know from having written my own heal scripts that it's not needed.
When it works, it's by accident.