- ceph-users - lists.ceph.io

Re: "cephadm shell" container missing permissions?
by Eugen Block 29 Jun '26

29 Jun '26

You need to specify the daemon: cephadm shell --name osd.X Then the device should be visible within the shell. And please don’t use ceph-volume on an orchestrated cluster outside of the shell. This will most likely cause issues. Zitat von mailing-lists via ceph-users <ceph-users(a)ceph.io>: > Hey Cephers, > > The big picture is, that I am trying to migrate a DB to a different > DB-Device. I used to do this many times on Ubuntu 22.04 and > Reef. With Ubuntu 24.04 and Squid however, I am facing a "permission > denied" scenario, that I do not understand. It seems like the > "cephadm shell" container is missing permissions to interact with > /dev/ceph-* lvs. > > Our setup is containerized with Docker and deployed with cephadm. > > > From within "cephadm shell": > > "ls -alh > /dev/ceph-0bafc014-2bc6-4ecf-96a2-80b2dd414ad2/osd-block-91ae2955-577a-4722-8548-5e78372f065 > > ls: cannot access > '/dev/ceph-0bafc014-2bc6-4ecf-96a2-80b2dd414ad2/osd-block-91ae2955-577a-4722-8548-5e78372f0650': No such file or > directory" > > From root on the same host: > "ls -alh > /dev/ceph-0bafc014-2bc6-4ecf-96a2-80b2dd414ad2/osd-block-91ae2955-577a-4722-8548-5e78372f0650 lrwxrwxrwx 1 root root 7 Jun 25 17:12 /dev/ceph-0bafc014-2bc6-4ecf-96a2-80b2dd414ad2/osd-block-91ae2955-577a-4722-8548-5e78372f0650 -> > ../dm-3" > > The container just cannot "see" the lv-device. > > Something like > > "ceph-volume lvm activate 1 91ae2955-577a-4722-8548-5e78372f0650" > > will then just fail with: > ``` > Running command: /usr/bin/ceph-authtool --gen-print-key > Running command: /usr/bin/ceph-authtool --gen-print-key > Running command: /usr/bin/chown -R ceph:ceph /var/lib/ceph/osd/ceph-1 > Running command: /usr/bin/ceph-bluestore-tool --cluster=ceph > prime-osd-dir --dev > /dev/ceph-0bafc014-2bc6-4ecf-96a2-80b2dd414ad2/osd-block-91ae2955-577a-4722-8548-5e78372f0650 --path /var/lib/ceph/osd/ceph-1 > --no-mon-config > stderr: failed to read label for > /dev/ceph-0bafc014-2bc6-4ecf-96a2-80b2dd414ad2/osd-block-91ae2955-577a-4722-8548-5e78372f0650: (1) *Operation not > permitted* > stderr: 2026-06-29T15:57:48.848+0000 7e8959bbca80 -1 > bdev(0x5d2610965800 > /dev/ceph-0bafc014-2bc6-4ecf-96a2-80b2dd414ad2/osd-block-91ae2955-577a-4722-8548-5e78372f0650) open stat got: (1) Operation not > permitted > --> RuntimeError: command returned non-zero exit status: 1 > > ``` > > Has anyone had this problem and solved it? > > Is the recommended way to install ceph utilities like ceph-volume on > the host instead using the toolkit from the cephadm shell? > > > Best > > _______________________________________________ > ceph-users mailing list -- ceph-users(a)ceph.io > To unsubscribe send an email to ceph-users-leave(a)ceph.io

1 0

"cephadm shell" container missing permissions?
by mailing-lists 29 Jun '26

29 Jun '26

Hey Cephers, The big picture is, that I am trying to migrate a DB to a different DB-Device. I used to do this many times on Ubuntu 22.04 and Reef. With Ubuntu 24.04 and Squid however, I am facing a "permission denied" scenario, that I do not understand. It seems like the "cephadm shell" container is missing permissions to interact with /dev/ceph-* lvs. Our setup is containerized with Docker and deployed with cephadm. From within "cephadm shell": "ls -alh /dev/ceph-0bafc014-2bc6-4ecf-96a2-80b2dd414ad2/osd-block-91ae2955-577a-4722-8548-5e78372f065 0 ls: cannot access '/dev/ceph-0bafc014-2bc6-4ecf-96a2-80b2dd414ad2/osd-block-91ae2955-577a-4722-8548-5e78372f0650': No such file or directory" From root on the same host: "ls -alh /dev/ceph-0bafc014-2bc6-4ecf-96a2-80b2dd414ad2/osd-block-91ae2955-577a-4722-8548-5e78372f0650 lrwxrwxrwx 1 root root 7 Jun 25 17:12 /dev/ceph-0bafc014-2bc6-4ecf-96a2-80b2dd414ad2/osd-block-91ae2955-577a-4722-8548-5e78372f0650 -> ../dm-3" The container just cannot "see" the lv-device. Something like "ceph-volume lvm activate 1 91ae2955-577a-4722-8548-5e78372f0650" will then just fail with: ``` Running command: /usr/bin/ceph-authtool --gen-print-key Running command: /usr/bin/ceph-authtool --gen-print-key Running command: /usr/bin/chown -R ceph:ceph /var/lib/ceph/osd/ceph-1 Running command: /usr/bin/ceph-bluestore-tool --cluster=ceph prime-osd-dir --dev /dev/ceph-0bafc014-2bc6-4ecf-96a2-80b2dd414ad2/osd-block-91ae2955-577a-4722-8548-5e78372f0650 --path /var/lib/ceph/osd/ceph-1 --no-mon-config stderr: failed to read label for /dev/ceph-0bafc014-2bc6-4ecf-96a2-80b2dd414ad2/osd-block-91ae2955-577a-4722-8548-5e78372f0650: (1) *Operation not permitted* stderr: 2026-06-29T15:57:48.848+0000 7e8959bbca80 -1 bdev(0x5d2610965800 /dev/ceph-0bafc014-2bc6-4ecf-96a2-80b2dd414ad2/osd-block-91ae2955-577a-4722-8548-5e78372f0650) open stat got: (1) Operation not permitted --> RuntimeError: command returned non-zero exit status: 1 ``` Has anyone had this problem and solved it? Is the recommended way to install ceph utilities like ceph-volume on the host instead using the toolkit from the cephadm shell? Best

1 0

Re: squid 19.2.5 QE validation status
by Ilya Dryomov 29 Jun '26

29 Jun '26

On Mon, Jun 29, 2026 at 4:27 PM Yuri Weinstein via dev <dev(a)ceph.io> wrote: > > Details of this release are summarized here: > > https://tracker.ceph.com/issues/76983#note-2 > > Release Notes - TBD > LRC upgrade - N/A > > Note: please reply to this email with comments/approvals and also add your comments to the tracker above. > > Seeking approvals/reviews for: > > smoke: PASSED > > rados: Radek, Laura, Nitzan, Afreen, Travis > rgw: Adam Emerson > fs: Venky > orch/ceph-volume: Redouane & Guillaume > rbd: Ilya > krbd: Ilya rbd and krbd approved. Thanks, Ilya

1 0

Re: mgmt-gateway: hostnames in nginx configuration
by Redouane Kachach 29 Jun '26

29 Jun '26

Hi Robert, The behaviour is different bcz the code is shared with other dashboard usecases where the hostname is needed. Anyway I opened https://tracker.ceph.com/issues/77782 to address the inconsistency. Best, Redouane. On Fri, Jun 26, 2026 at 5:55 PM Robert Sander via ceph-users < ceph-users(a)ceph.io> wrote: > Hi, > > all upstream configuration sections in nginx.conf of the mgmt-gateway > service use the IP addresses of the hosts in question. > > Except of the dashboard section which uses the hostname. > > Why is that implemented this way? > > We stumbled across this as the hostname resolves to an IP address > different from the Ceph public network. This means port 8443 is not > reachable via this IP. > > If the dashboard section would also use the IP address from the > orchestrator's host list this would work. > > Regards > -- > Robert Sander > Linux Consultant > > Heinlein Consulting GmbH > Schwedter Str. 8/9b, 10119 Berlin > > https://www.heinlein-support.de > > Tel: +49 30 405051 - 0 > Fax: +49 30 405051 - 19 > > Amtsgericht Berlin-Charlottenburg - HRB 220009 B > Geschäftsführer: Peer Heinlein - Sitz: Berlin > _______________________________________________ > ceph-users mailing list -- ceph-users(a)ceph.io > To unsubscribe send an email to ceph-users-leave(a)ceph.io > >

1 0

CEPHADM_FAILED_DAEMON: OSDs in error state but containers running fine (19.2.3/Squid)
by Sroush Pasandideh 29 Jun '26

29 Jun '26

Hi all, Ceph 19.2.3 (Squid), cephadm-deployed, 528 OSDs. After a drive failure on one host (sdc, ~10 min of SCSI retry stalls at boot), ceph health detail now reports 13 CEPHADM_FAILED_DAEMON warnings on that host: daemon osd.266 on ceph-bh03 is in error state daemon osd.267 on ceph-bh03 is in error state ... (13 total) ceph orch ps confirms the same 13 as error. But checking each container directly: podman ps -a --filter name=osd.275 ... Up 3 days 12 of the 13 containers are running fine, no restarts, clean RocksDB stats in their logs. Only 1 (the OSD that actually sat on the dead drive) has no container at all. So it looks like cephadm's daemon-state cache went stale for the 12 healthy ones. Has anyone seen this before? Is "ceph mgr fail" the right way to force a clean orchestrator re-sync here, or is there a more targeted fix (per-daemon redeploy, restarting the cephadm mgr module)? Thanks, Soroush -- Soroush Pasandideh | Universität Osnabrück - Rechenzentrum | 0541 969 2336

1 0

Re: Deploying newer Ganesha version with older Ceph release
by Nigel Williams 29 Jun '26

29 Jun '26

On Sun, 28 Jun 2026 at 23:39, Arcartis via ceph-users <ceph-users(a)ceph.io> wrote: several good questions about Ganesha versions etc. Thank you for asking these questions, we have been wondering about the same things.

1 0

Deep scrub throughput significantly decreased after upgrade from 19.2.3 to 20.2.1
by Kamil Madac 28 Jun '26

28 Jun '26

Hi, after upgrading one of our production clusters from Ceph 19.2.3 to 20.2.1 we observed that deep scrubbing is no longer keeping up with the configured schedule. The cluster is healthy apart from: HEALTH_WARN 400 pgs not deep-scrubbed in time The number of overdue PGs is steadily increasing (e.g. 0 -> 400 within 4 days). Cluster Ceph 20.2.1 (upgraded from 19.2.3 approximately one week ago) 18 OSDs NVMe SSDs 2208 PGs ~27 TiB user data ~64% raw utilization No recovery/backfill All PGs are active+clean 18 osds: 18 up, 18 in flags: noautoscale OSD latencies are essentially zero: ceph osd perf commit_latency = 0 ms apply_latency = 0 ms Scrub configuration The scrub window has been unchanged for a long time: osd_scrub_begin_hour = 21 osd_scrub_end_hour = 6 The cluster kept up with this configuration before the upgrade. The scheduler configuration is: osd_op_queue = mclock_scheduler osd_mclock_profile = high_recovery_ops This profile was already configured before the upgrade. Observation: I collect the ceph_pg_scrubbing Prometheus metric. Before the upgrade (19.2.3): scrubbing starts around 23:00 continues throughout the whole scrub window there are continuously 1-5 PGs being scrubbed during the night After the upgrade (20.2.1): there is a large initial burst (around 30 PGs scrubbing simultaneously) after that, scrubbing almost completely stops only occasional individual PGs are scrubbed during the rest of the scrub window As a result, the number of overdue deep scrubs increases every day. Questions: Were there any changes to scrub scheduling or mClock behavior between 19.2.3 and 20.2.1 that could explain this? Is this a known issue in 20.2.1? Is high_recovery_ops known to affect deep scrub scheduling differently in Ceph 20 compared to Ceph 19? Are there any debug commands or perf counters that would help determine why new scrub jobs are not being scheduled after the initial burst? I'd appreciate any suggestions on what to investigate next. Thanks! Kamil Madac

1 0

Re: Tentacle 20.2.1 - All MGRs failed
by Anthony D'Atri 28 Jun '26

28 Jun '26

Something else to try might be to delete the .mgr pool and let it be recreated. > On Jun 28, 2026, at 9:31 AM, Eugen Block via ceph-users <ceph-users(a)ceph.io> wrote: > > Hi, > > I don’t have a response to all your questions, but will try to answer a few. > > Zitat von Chris Palmer via ceph-users <ceph-users(a)ceph.io>: > >> Due to a number of power and heat events, I had to power down a small ceph cluster last night. There was only time to do a operating system shutdown of all nodes. >> >> When the systems rebooted a few hours later, all was ok except that all 3 MGRs would abort and restart until they reached the restart limit. This left the system with no MGRs and no orchestration. All OSD, MDS, RGW & monitoring subsystems were working as normally as could be expected without an MGR. >> >> Analysis of the log files showed each MGR aborting with the assertion below. Every one was in the telemetry thread. I disabled telemetry and the MGRs could be restarted normally. Questions: >> >> * What caused the assertion error? Was it related to the total shutdown? >> * Aborting the entire MGR seems overkill. Disabling the telemetry >> module and raising a warning seems more proportionate. >> * When running with no active MGR the client IO stats in ceph -s were >> frozen (at plausible non-zero values). Is that expected with no >> active MGR? > > Yes, OSDs report their stats to the MGR which is responsible for displaying those in tje status. > >> * With no active MGR a large number of deep-scrubs started - roughly 3 >> times the maximum number we ever see were actively deep-scrubbing, >> with none in the scrub wait state, and response times were horrible. >> Is this expected with no MGR to control it properly? I had to >> temporarily disable scrubs and deep-scrubs as a workaround. > > I see the same after restarting an entire cluster (mostly in small lab environments), I don’t think that has to do with no active mgr. Although mgr and osd have each a deep-scrub interval, the OSDs are responsible for scheduling. So this is most likely just how OSDs work after a cluster reboot. > >> I haven't yet tried 20.2.2, but I couldn't see anything obvious in the release notes. (Although there were about 3 PRs that I thought might have had the potential to upset exception handling...). >> >> Thanks, Chris >> >> >> { >> "crash_id": "2026-06-26T01:46:00.265207Z_b0579062-d65c-4a51-8dbc-d9837209aa80", >> "timestamp": "2026-06-26T01:46:00.265207Z", >> "process_name": "ceph-mgr", >> "entity_name": "mgr.ceph2", >> "ceph_version": "20.2.1", >> "utsname_hostname": "ceph2", >> "utsname_sysname": "Linux", >> "utsname_release": "7.0.12-201.fc44.x86_64", >> "utsname_version": "#1 SMP PREEMPT_DYNAMIC Thu Jun 11 01:30:16 UTC 2026", >> "utsname_machine": "x86_64", >> "os_name": "CentOS Stream", >> "os_id": "centos", >> "os_version_id": "9", >> "os_version": "9", >> "assert_condition": "cursor != root", >> "assert_func": "virtual void PyFormatter::close_section()", >> "assert_file": "/ceph/rpmbuild/BUILD/ceph-20.2.1/src/mgr/PyFormatter.h", >> "assert_line": 84, >> "assert_thread_name": "telemetry", >> "assert_msg": "/ceph/rpmbuild/BUILD/ceph-20.2.1/src/mgr/PyFormatter.h: In function 'virtual void PyFormatter::close_section()' thread 7f752186e640 time 2026-06-26T01:46:00.263380+0000\n/ceph/rpmbuild/BUILD/ceph-20.2.1/src/mgr/PyFormatter.h: 84: FAILED ceph_assert(cursor != root)\n", >> "backtrace": [ >> "/lib64/libc.so.6(+0x3fc30) [0x7f75a9eb8c30]", >> "/lib64/libc.so.6(+0x8d05c) [0x7f75a9f0605c]", >> "raise()", >> "abort()", >> "(ceph::__ceph_assert_fail(char const*, char const*, int, char const*)+0x18e) [0x7f75aa9ed95b]", >> "/usr/bin/ceph-mgr(+0x6f7a5) [0x55ac462367a5]", >> "(ActivePyModules::get_perf_schema_python(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)+0x15a3) [0x55ac462d3143]", >> "/usr/bin/ceph-mgr(+0x12ba12) [0x55ac462f2a12]", >> "/lib64/libpython3.9.so.1.0(+0x15b4b7) [0x7f75ab5e34b7]", >> "_PyEval_EvalFrameDefault()", >> "/lib64/libpython3.9.so.1.0(+0x14169b) [0x7f75ab5c969b]", >> "_PyEval_EvalFrameDefault()", >> "/lib64/libpython3.9.so.1.0(+0x12ec69) [0x7f75ab5b6c69]", >> "_PyFunction_Vectorcall()", >> "_PyEval_EvalFrameDefault()", >> "/lib64/libpython3.9.so.1.0(+0x12ec69) [0x7f75ab5b6c69]", >> "_PyFunction_Vectorcall()", >> "_PyEval_EvalFrameDefault()", >> "/lib64/libpython3.9.so.1.0(+0x12ec69) [0x7f75ab5b6c69]", >> "_PyFunction_Vectorcall()", >> "_PyEval_EvalFrameDefault()", >> "/lib64/libpython3.9.so.1.0(+0x12ec69) [0x7f75ab5b6c69]", >> "_PyFunction_Vectorcall()", >> "_PyEval_EvalFrameDefault()", >> "/lib64/libpython3.9.so.1.0(+0x14169b) [0x7f75ab5c969b]", >> "/lib64/libpython3.9.so.1.0(+0x14fa85) [0x7f75ab5d7a85]", >> "/lib64/libpython3.9.so.1.0(+0x138725) [0x7f75ab5c0725]", >> "_PyObject_CallMethod_SizeT()", >> "(PyModuleRunner::serve()+0x66) [0x55ac463759e6]", >> "(PyModuleRunner::PyModuleRunnerThread::entry()+0x139) [0x55ac463761e9]", >> "/lib64/libc.so.6(+0x8b31a) [0x7f75a9f0431a]" >> ] >> } >> _______________________________________________ >> ceph-users mailing list -- ceph-users(a)ceph.io >> To unsubscribe send an email to ceph-users-leave(a)ceph.io > > > _______________________________________________ > ceph-users mailing list -- ceph-users(a)ceph.io > To unsubscribe send an email to ceph-users-leave(a)ceph.io

1 0

Deploying newer Ganesha version with older Ceph release
by Arcartis 28 Jun '26

28 Jun '26

Hi all, can someone tell me why Ceph Squid comes with such an old Ganesha version (5.9)? We are seeing issues with File Locks that cannot be explained, and that I would like to resolve. It does not seem individual components can be upgraded without upgrading the whole cluster. Red Hat has recently commited a code change (https://github.com/nfs-ganesha/nfs-ganesha/commit/baa956ab280ba5a0c42219efd…) that seems like it could be related and mitigate this. But only for Ganesha V10 and not yet in the stable Ceph release if I am not mistaken. I would like to know what is considered stable for Ganesha in relation to the Ceph releases. Has anybody information on this? A compatibility matrix would be great, perhaps I missed something. I want to make sure that e.g. Ganesha V10 isn't causing issues with Ceph Squid or Tentacle FSAL backends. It is on the table to decomission the cephadm NFS daemons and deploy a standalone Ganesha version 10 on the Ceph nodes outside of the orchestrator. I have my reservations that this is a good idea for production. Any guidance is appreciated! Thanks

1 0

Re: Tentacle 20.2.1 - All MGRs failed
by Eugen Block 28 Jun '26

28 Jun '26

Hi, I don’t have a response to all your questions, but will try to answer a few. Zitat von Chris Palmer via ceph-users <ceph-users(a)ceph.io>: > Due to a number of power and heat events, I had to power down a > small ceph cluster last night. There was only time to do a operating > system shutdown of all nodes. > > When the systems rebooted a few hours later, all was ok except that > all 3 MGRs would abort and restart until they reached the restart > limit. This left the system with no MGRs and no orchestration. All > OSD, MDS, RGW & monitoring subsystems were working as normally as > could be expected without an MGR. > > Analysis of the log files showed each MGR aborting with the > assertion below. Every one was in the telemetry thread. I disabled > telemetry and the MGRs could be restarted normally. Questions: > > * What caused the assertion error? Was it related to the total shutdown? > * Aborting the entire MGR seems overkill. Disabling the telemetry > module and raising a warning seems more proportionate. > * When running with no active MGR the client IO stats in ceph -s were > frozen (at plausible non-zero values). Is that expected with no > active MGR? Yes, OSDs report their stats to the MGR which is responsible for displaying those in tje status. > * With no active MGR a large number of deep-scrubs started - roughly 3 > times the maximum number we ever see were actively deep-scrubbing, > with none in the scrub wait state, and response times were horrible. > Is this expected with no MGR to control it properly? I had to > temporarily disable scrubs and deep-scrubs as a workaround. I see the same after restarting an entire cluster (mostly in small lab environments), I don’t think that has to do with no active mgr. Although mgr and osd have each a deep-scrub interval, the OSDs are responsible for scheduling. So this is most likely just how OSDs work after a cluster reboot. > I haven't yet tried 20.2.2, but I couldn't see anything obvious in > the release notes. (Although there were about 3 PRs that I thought > might have had the potential to upset exception handling...). > > Thanks, Chris > > > { > "crash_id": > "2026-06-26T01:46:00.265207Z_b0579062-d65c-4a51-8dbc-d9837209aa80", > "timestamp": "2026-06-26T01:46:00.265207Z", > "process_name": "ceph-mgr", > "entity_name": "mgr.ceph2", > "ceph_version": "20.2.1", > "utsname_hostname": "ceph2", > "utsname_sysname": "Linux", > "utsname_release": "7.0.12-201.fc44.x86_64", > "utsname_version": "#1 SMP PREEMPT_DYNAMIC Thu Jun 11 01:30:16 UTC 2026", > "utsname_machine": "x86_64", > "os_name": "CentOS Stream", > "os_id": "centos", > "os_version_id": "9", > "os_version": "9", > "assert_condition": "cursor != root", > "assert_func": "virtual void PyFormatter::close_section()", > "assert_file": "/ceph/rpmbuild/BUILD/ceph-20.2.1/src/mgr/PyFormatter.h", > "assert_line": 84, > "assert_thread_name": "telemetry", > "assert_msg": > "/ceph/rpmbuild/BUILD/ceph-20.2.1/src/mgr/PyFormatter.h: In function > 'virtual void PyFormatter::close_section()' thread 7f752186e640 time > 2026-06-26T01:46:00.263380+0000\n/ceph/rpmbuild/BUILD/ceph-20.2.1/src/mgr/PyFormatter.h: 84: FAILED ceph_assert(cursor != > root)\n", > "backtrace": [ > "/lib64/libc.so.6(+0x3fc30) [0x7f75a9eb8c30]", > "/lib64/libc.so.6(+0x8d05c) [0x7f75a9f0605c]", > "raise()", > "abort()", > "(ceph::__ceph_assert_fail(char const*, char const*, int, char > const*)+0x18e) [0x7f75aa9ed95b]", > "/usr/bin/ceph-mgr(+0x6f7a5) [0x55ac462367a5]", > "(ActivePyModules::get_perf_schema_python(std::__cxx11::basic_string<char, > std::char_traits<char>, std::allocator<char> > const&, > std::__cxx11::basic_string<char, std::char_traits<char>, > std::allocator<char> > const&)+0x15a3) [0x55ac462d3143]", > "/usr/bin/ceph-mgr(+0x12ba12) [0x55ac462f2a12]", > "/lib64/libpython3.9.so.1.0(+0x15b4b7) [0x7f75ab5e34b7]", > "_PyEval_EvalFrameDefault()", > "/lib64/libpython3.9.so.1.0(+0x14169b) [0x7f75ab5c969b]", > "_PyEval_EvalFrameDefault()", > "/lib64/libpython3.9.so.1.0(+0x12ec69) [0x7f75ab5b6c69]", > "_PyFunction_Vectorcall()", > "_PyEval_EvalFrameDefault()", > "/lib64/libpython3.9.so.1.0(+0x12ec69) [0x7f75ab5b6c69]", > "_PyFunction_Vectorcall()", > "_PyEval_EvalFrameDefault()", > "/lib64/libpython3.9.so.1.0(+0x12ec69) [0x7f75ab5b6c69]", > "_PyFunction_Vectorcall()", > "_PyEval_EvalFrameDefault()", > "/lib64/libpython3.9.so.1.0(+0x12ec69) [0x7f75ab5b6c69]", > "_PyFunction_Vectorcall()", > "_PyEval_EvalFrameDefault()", > "/lib64/libpython3.9.so.1.0(+0x14169b) [0x7f75ab5c969b]", > "/lib64/libpython3.9.so.1.0(+0x14fa85) [0x7f75ab5d7a85]", > "/lib64/libpython3.9.so.1.0(+0x138725) [0x7f75ab5c0725]", > "_PyObject_CallMethod_SizeT()", > "(PyModuleRunner::serve()+0x66) [0x55ac463759e6]", > "(PyModuleRunner::PyModuleRunnerThread::entry()+0x139) [0x55ac463761e9]", > "/lib64/libc.so.6(+0x8b31a) [0x7f75a9f0431a]" > ] > } > _______________________________________________ > ceph-users mailing list -- ceph-users(a)ceph.io > To unsubscribe send an email to ceph-users-leave(a)ceph.io

1 0