On Mon, Mar 18, 2019 at 10:06 AM Milind Changire <mchangir(a)redhat.com> wrote:
On Sun, Mar 17, 2019 at 4:40 PM Jeff Layton <jlayton(a)redhat.com> wrote:
On Sun, 2019-03-17 at 09:39 +0530, Milind Changire wrote:
I could run cephfs-shell without 'make
install'.
After running vstart, cd to build directory and run:
$ LD_LIBRARY_PATH=$PWD/lib python3.7 ../src/tools/cephfs/cephfs-shell --config ceph.conf
The ceph.conf is generated when vstart is executed. I guess you'd know this part.
On Sat, Mar 16, 2019 at 4:40 PM Jeff Layton <jlayton(a)redhat.com> wrote:
> I need to do a bit of testing with cephfs and would like to avoid having
> to use FUSE or write C calls into libcephfs. cephfs-shell seems perfect
> for this, but I haven't quite figured out how to run it out of the build
> directory.
>
> Is there a way to run cephfs-shell from a ceph build directory (i.e. w/o
> make installing it)? Are there env vars that can be set to make it find
> the right bits in the right places?
>
> Thanks,
> --
> Jeff Layton <jlayton(a)redhat.com>
> _______________________________________________
> ceph-fs mailing list -- ceph-fs(a)ceph.io
> To unsubscribe send an email to ceph-fs-leave(a)ceph.io
Thanks Milind,
Hmm...that didn't work for me:
$ LD_LIBRARY_PATH=$PWD/lib python3.7 ../src/tools/cephfs/cephfs-shell --config ceph.conf
Traceback (most recent call last):
File "../src/tools/cephfs/cephfs-shell", line 9, in <module>
import cephfs as libcephfs
ModuleNotFoundError: No module named 'cephfs'
sorry about that ... I too tried a number of things
you probably want to run the following command under the build directory:
$ sudo ldconfig $PWD/lib
and then run the command I mentioned earlier.
Also, I had indeed done a sudo make install before I figured out the LD_LIBRARY_PATH
kludge ... but now have found the following python shared objects even after a make
uninstall. I wonder if these are the files that help in running the cephfs-shell:
$ find /usr/local/lib64/python3.7/site-packages/ -name '*.so'
/usr/local/lib64/python3.7/site-packages/rados.cpython-37m-x86_64-linux-gnu.so
/usr/local/lib64/python3.7/site-packages/cephfs.cpython-37m-x86_64-linux-gnu.so
/usr/local/lib64/python3.7/site-packages/rgw.cpython-37m-x86_64-linux-gnu.so
/usr/local/lib64/python3.7/site-packages/rbd.cpython-37m-x86_64-linux-gnu.so
Also, the above shared objects are not owned by any RPM. So, looks like they never got
cleaned up by the make uninstall.
$ rpm -q --whatprovides
/usr/local/lib64/python3.7/site-packages/cephfs.cpython-37m-x86_64-linux-gnu.so
file /usr/local/lib64/python3.7/site-packages/cephfs.cpython-37m-x86_64-linux-gnu.so is
not owned by any package
May be there are other libs left over by the make unsintall that are helping me run the
cephfs-shell.
I'm guessing maybe you have a python3-cephfs
module installed on your
machine?
No python3-cephfs on my system:
$ rpm -q python3-cephfs
package python3-cephfs is not installed
In any case I tried this and it got me a little closer:
$ PYTHONPATH=../src/pybind LD_LIBRARY_PATH=$PWD/lib python3.7
../src/tools/cephfs/cephfs-shell --config ceph.conf
Traceback (most recent call last):
File "../src/tools/cephfs/cephfs-shell", line 974, in <module>
setup_cephfs(config_file)
File "../src/tools/cephfs/cephfs-shell", line 59, in setup_cephfs
cephfs = libcephfs.LibCephFS(conffile=config_file)
AttributeError: module 'cephfs' has no attribute 'LibCephFS'
...but I think it didn't import the module as expected. I'll keep
tinkering with it tomorrow.
Cheers,
--
Jeff Layton <jlayton(a)redhat.com>
I just noticed that the following lines are emitted by the vtstart script right at the
end:
export
PYTHONPATH=./pybind:/home/mchangir/work/ceph.git/src/pybind:/home/mchangir/work/ceph.git/build/lib/cython_modules/lib.3:
export LD_LIBRARY_PATH=/home/mchangir/work/ceph.git/build/lib
CEPH_DEV=1
Maybe, these will help ?
After I executed the above lines in my shell and moved out the libs under the
/usr/local/lib64/python3.7/site-packages to a temporary directory, I could run
cephfs-shell without any problems. I didn't need to prefix the command with
LD_LIBRARY_PATH since that's exactly what the vstart script spewed out.