My Ceph cluster(s) usually run on openSUSE, in this case Leap 15.6. The host directory /var/lib/ceph/crash/posted is created by the 'ceph-base' package, so I removed that (this is a test machine for all kinds of purposes). I redeployed with cephadm (I don't use FQDN) and it creates the directory /var/lib/ceph/{FSID}/crash/posted for me. I don't see a warning about this directory. So just to clarify, is it complaining about the host directory /var/lib/ceph/crash/posted not being present or the "mapped" directory within the ceph-crash container? There have been a couple of releases which don't handle crash well in general. I haven't look too deep into the latest though. As for the cephadm shell, what das 'cephadm ls --no-detail | grep crash' show you? If you deployed with FQDN, I'd expect that crash is also deployed with FQDN. But $HOSTNAME could be the shortname, so you probably should use a different approach, for example 'cephadm shell --name crash.$(hostname -f) or something similar. Zitat von lejeczek <peljasz@yahoo.co.uk>:
no 'ceph-crush' installed as far as I can tell.
-> $ rpm -qa \*ceph\* centos-release-ceph-squid-1.0-1.el9s.noarch python3-ceph-argparse-19.2.3-1.el9s.x86_64 libcephfs2-19.2.3-1.el9s.x86_64 python3-cephfs-19.2.3-1.el9s.x86_64 python3-ceph-common-19.2.3-1.el9s.x86_64 ceph-common-19.2.3-1.el9s.x86_64 cephadm-19.2.3-1.el9s.noarch
cluster was deployed with -> $ cephadm bootstrap ...
What also is "interesting" is: -> $ cephadm shell --name crash.$HOSTNAME Inferring fsid 9f4f9dba-72c7-11f0-8052-525400519d29 Inferring config /var/lib/ceph/9f4f9dba-72c7-11f0-8052-525400519d29/crash.podster1.mine.priv/config Using ceph image with id 'aade1b12b8e6' and tag 'v19' created on 2025-07-17 19:53:27 +0000 UTC quay.io/ceph/ceph@sha256:af0c5903e901e329adabe219dfc8d0c3efc1f05102a753902f33ee16c26b6cee Error: statfs /var/lib/ceph/9f4f9dba-72c7-11f0-8052-525400519d29/crash.podster1.mine.priv/keyring: no such file or directory
and that is for all nodes. But I find: /var/lib/ceph/9f4f9dba-72c7-11f0-8052-525400519d29/crash/posted/ on all/each node - which path _was_ created by the cluster (as opposed to human) also, I find: /var/lib/ceph/9f4f9dba-72c7-11f0-8052-525400519d29/crash.podster3/keyring also on each node, which seems to contain other configs - as 'shell --name ...' above, was looking for.
No, failing mon I thought I should have mentioned it only as trace of originating issue - but I did not think of causality. Is this some hostnames / FQDN misconfiguration ? but if so, then that was/is cluster/cephadm on its own. OS resolver check /etc/hosts - DNS also involved later - which contains: -> $ cat /etc/hosts 127.0.0.1 localhost localhost.localdomain localhost4 localhost4.localdomain4 ::1 localhost localhost.localdomain localhost6 localhost6.localdomain6
10.1.1.61 podster1.mine.priv podster1 10.1.1.62 podster2.mine.priv podster2 10.1.1.63 podster3.mine.priv podster3
I added hosts to the cluster - and 'bootstraped' - with their FQDNs.
thanks, L. _______________________________________________ ceph-users mailing list -- ceph-users@ceph.io To unsubscribe send an email to ceph-users-leave@ceph.io