Building without tests worked and I am now operational once again.
___
ceph-users mailing list -- ceph-users@ceph.io
To unsubscribe send an email to ceph-users-le...@ceph.io
I am having little luck building ceph on Debian bullseye. First of all
if I install the package ninja-build and run ninja in the build
directory, I get an error that ninja.build file is not found after
running ./do_cmake.sh. I am thus just executing make, which is failing
to compile some tests. I a
Yes, I have all MDS running now and I am in the process of building
ceph sources with your patch from the original thread. I also tried
the command:
ceph fs compat prod add_incompat 7 "mds uses inline data"
Since I noticed that option was defined for two of the three file
systems (the working one
OK, so you are in the same situation as mine.
I would expect that you can keep the mon up without gdb if you set the max_mds
of prod back to 3. Then you should try to revert the ‘rmfailed’ by either
building your own ‘addfailed’ command or using the one built by Patrick.
Details can be found in
Thanks for your reply.
I tried something similar (but wrong) based on your messages in the
referenced threads, but I was missing the "gdb commands...end"
sequence so I just kept hitting my breakpoint over and over. However,
I was able to get the monitor running with your guidance.
Indeed, ceph rm
Hi Ben,
This looks a lot like the issue I had. Do you know what caused this crashing?
In my case, I issued “ceph mds rmfailed”. Did you also issued this command?
Here is what I did to prevent the crash, if I recall it correctly. In gdb,
before running the mon:
(gdb) b MDSMonitor::maybe_resize_
A colleague asked me to take a look at a Ceph cluster that has stopped working.
The "ceph -s" command (any ceph command) just times out.
Of three monitors two are crashing with:
(gdb) bt
#0 0x7fffee17b7bb in raise () from /lib/x86_64-linux-gnu/libc.so.6
#1 0x7fffee166535 in abort () f
