Подскажите куда копать, монитор выпал из кворума и не джойнится. На сломаном мониторе в логах:
mon.ceph-prod-2 e1 handle_auth_bad_method hmm, they didn't like 2 result (13) Permission denied

keyring на месте

-rw------- 1 ceph ceph 77 Apr  6 13:45 /var/lib/ceph/mon/ceph-ceph-prod-2/keyring

а версия мониторов какая? и какая версия у того, что не подключается?

судя по исходникам эта ошибка возникает из-за того что старая версия протокола аутенфикации не поддерживается. был апгрейд какой-то?

Апгрейда не было, просто перезагрузка монитора и после ребута он не заехал в кворум

версия у всех одинаковая ceph version 15.2.10

внутренности keyring совпадают с тем что на других мониторах?

Да, проверил это

если мониторы создали кворум, то может тогда пересоздать проблемный? А так можно на всякий случай сделать ceph auth get mon. -o /var/lib/ceph/mon/ceph-ceph-prod-2/keyring

Ребят, всем добрый день, подскажите что и куда смотреть, падают время от времени mds демоны на 15.2.12(падали и раньше когда версия была 15.2.8, обновление не помогло). Ошибка всегда одинаковая, судя по выводу ceph crash info, частота падения всегда разная, но всегда под нагрузкой (ночью и на выходных не падают), иногда раз в неделю иногда несколько раз за день.

Собственно вывод ceph crash info

   "assert_condition": "linkage.is_null()",
    "assert_file": "/home/jenkins-build/build/workspace/ceph-build/ARCH/x86_64/AVAILABLE_ARCH/x86_64/AVAILABLE_DIST/centos7/DIST/centos7/MACHINE_SIZE/gigantic/release/15.2.12/rpm/el7/BUILD/ceph-15.2.12/src/mds/CDentry.cc",
    "assert_func": "virtual void CDentry::decode_lock_state(int, const bufferlist&)",
    "assert_line": 445,
    "assert_msg": "/home/jenkins-build/build/workspace/ceph-build/ARCH/x86_64/AVAILABLE_ARCH/x86_64/AVAILABLE_DIST/centos7/DIST/centos7/MACHINE_SIZE/gigantic/release/15.2.12/rpm/el7/BUILD/ceph-15.2.12/src/mds/CDentry.cc: In function 'virtual void CDentry::decode_lock_state(int, const bufferlist&)' thread 7f02e5467700 time 2021-05-27T14:49:48.829303+0300\n/home/jenkins-build/build/workspace/ceph-build/ARCH/x86_64/AVAILABLE_ARCH/x86_64/AVAILABLE_DIST/centos7/DIST/centos7/MACHINE_SIZE/gigantic/release/15.2.12/rpm/el7/BUILD/ceph-15.2.12/src/mds/CDentry.cc: 445: FAILED ceph_assert(linkage.is_null())\n",
    "assert_thread_name": "ms_dispatch",
    "backtrace": [
        "(()+0xf630) [0x7f02ecdff630]",
        "(gsignal()+0x37) [0x7f02eb9dc3d7]",
        "(abort()+0x148) [0x7f02eb9ddac8]",
        "(ceph::__ceph_assert_fail(char const*, char const*, int, char const*)+0x19b) [0x7f02edf277ae]",
        "(()+0x269927) [0x7f02edf27927]",
        "(CDentry::decode_lock_state(int, ceph::buffer::v15_2_0::list const&)+0x2d4) [0x5622467d71b4]",
        "(Locker::handle_simple_lock(SimpleLock*, boost::intrusive_ptr<MLock const> const&)+0x3b5) [0x562246783db5]",
        "(Locker::handle_lock(boost::intrusive_ptr<MLock const> const&)+0x1ea) [0x56224678d9ea]",
        "(Locker::dispatch(boost::intrusive_ptr<Message const> const&)+0xbf) [0x56224678dbcf]",
        "(MDSRank::handle_message(boost::intrusive_ptr<Message const> const&)+0x6e4) [0x5622465ea5d4]",
        "(MDSRank::_dispatch(boost::intrusive_ptr<Message const> const&, bool)+0x7a3) [0x5622465ecb83]",
        "(MDSRankDispatcher::ms_dispatch(boost::intrusive_ptr<Message const> const&)+0x43) [0x5622465ed0a3]",
        "(MDSDaemon::ms_dispatch2(boost::intrusive_ptr<Message> const&)+0x118) [0x5622465db278]",
        "(DispatchQueue::entry()+0x11ba) [0x7f02ee13a6ca]",
        "(DispatchQueue::DispatchThread::entry()+0xd) [0x7f02ee1d7c6d]",
        "(()+0x7ea5) [0x7f02ecdf7ea5]",
        "(clone()+0x6d) [0x7f02ebaa49fd]"
    ],
    "ceph_version": "15.2.12",
    "crash_id": "2021-05-27T11:49:48.831844Z_3a8aa01d-2941-4656-a68b-28bea27246ea",
    "entity_name": "mds.sus-s04-17",
    "os_id": "centos",
    "os_name": "CentOS Linux",
    "os_version": "7 (Core)",
    "os_version_id": "7",
    "process_name": "ceph-mds",
    "stack_sig": "3c9f2027619e440306c86c122ad6558925efeba2bb5dda413a227a358e7355ff",
    "timestamp": "2021-05-27T11:49:48.831844Z",
    "utsname_hostname": "sus-s04-17.dc.rk",
    "utsname_machine": "x86_64",
    "utsname_release": "3.18.39",
    "utsname_sysname": "Linux",
    "utsname_version": "#1 SMP Wed Feb 17 17:11:02 MSK 2021"
}

Особо не могу нагуглить подобную проблему, у кого то что то похожее было только в 2016 на люминусе и то он там создал fs поверх пула уже содержащего данные и там вроде еще файлстор.

В качестве клиентов всего 3 ВМ с centos7 на борту, сейчас на клиентах стоковое 3.10 ветки ядро, пробовали также 5.12 из kernel-ml, один хрен не помогло, mds продолжают падать

думаю лучше написать в http://lists.ceph.com . Там разработчики живут, мне не раз подсказывали, даже issue заводили

Хотя сейчас может лучше в раздел issues в их git написать

ceph::buffer::v15_2_0

15.2.8 и 15.2.12 говорите?

да, версии такие. Верхнюю строчку начинать искать на трекере где то?

Может у вас ceph-common или какой-нибудь librados не той версии?

сейчас по нодам проверю. Выхлоп ceph versions одинаков

{
    "mon": {
        "ceph version 15.2.12 (ce065eabfa5ce81323b009786bdf5bb03127cbe1) octopus (stable)": 5
    },
    "mgr": {
        "ceph version 15.2.12 (ce065eabfa5ce81323b009786bdf5bb03127cbe1) octopus (stable)": 3
    },
    "osd": {
        "ceph version 15.2.12 (ce065eabfa5ce81323b009786bdf5bb03127cbe1) octopus (stable)": 114
    },
    "mds": {
        "ceph version 15.2.12 (ce065eabfa5ce81323b009786bdf5bb03127cbe1) octopus (stable)": 7
    },
    "overall": {
        "ceph version 15.2.12 (ce065eabfa5ce81323b009786bdf5bb03127cbe1) octopus (stable)": 129
    }
}

прошелся по нодам на всяк, везде 15.2.12, и librados и ceph-common, вообще все пакеты содержащие ceph в имени на всех нодах имеют также 15.2.12 кроме утилиты сефдеплой