Re: glfsheal test failures

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 12/11/2014 06:30 PM, Jeff Darcy wrote:
> Running ldconfig doesn't fix it.  This is a Fedora 20 system, BTW.

Strange, works every single time for me in a F20/ RHS machines:
[ravi@tuxpad ~]$ ldd /usr/local/sbin/glfsheal |grep afr
        afr.so => /usr/local/lib/glusterfs/3.7dev/xlator/cluster/afr.so (0x00007ff8c5d1e000)

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

Okay, I'll work a patch with the dlopen/dlsym approach.
That should also fix the compile warnings that Emmanuel pointed out.

I have a few noob doubts though:

1. The glfsheal makefile also links it to other .SOs (libglusterfs, libgfapi etc). Is that OK to do?
Is it just linking against a translator module that is incorrect?

2. dlopen("afr,so",flags) also looks for the object in predefined locations listed in `man 3 dlopen`. That
makes me wonder if you would still end up hitting the same issue where afr.so cannot be found.I say this
because you have it installed on your F20 system but the loader(?) is not able to locate it unless you are
explicitly set it via LD_LIBRARY_PATH.


> When it works, it's by accident.

All my machines seem to be accident prone :-)

Regards,
Ravi
_______________________________________________
Gluster-devel mailing list
Gluster-devel@xxxxxxxxxxx
http://supercolony.gluster.org/mailman/listinfo/gluster-devel




[Index of Archives]     [Gluster Users]     [Ceph Users]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux