On 2020-12-01 13:19, Oliver Weinmann wrote:
podman ps -a didn't show that container. So I googled and stumbled over
this post:
https://github.com/containers/podman/issues/2553
I was able to fix it by running:
podman rm --storage
e43f8533d6418267d7e6f3a408a566b4221df4fb51b13d71c634ee697914bad6
After that I reset the failure of the service and started it again.
systemctl reset-failed
ceph-d0920c36-2368-11eb-a5de-005056b703af(a)osd.0.service
systemctl start ceph-d0920c36-2368-11eb-a5de-005056b703af(a)osd.0.service
Ah, I had this issue once with my first venture into Ceph and docker.
There might be a "kill container" option in cephadm, just to make sure
it cleans up the container bit. I haven't touched cephadm yet, but IIRC
there is such an option.
Now ceph is doing its magic :)
Great!
[root@gedasvl02 ~]# ceph -s
INFO:cephadm:Inferring fsid d0920c36-2368-11eb-a5de-005056b703af
INFO:cephadm:Inferring config
/var/lib/ceph/d0920c36-2368-11eb-a5de-005056b703af/mon.gedasvl02/config
INFO:cephadm:Using recent ceph image docker.io/ceph/ceph:v15
cluster:
id: d0920c36-2368-11eb-a5de-005056b703af
health: HEALTH_WARN
Degraded data redundancy: 1941/39432 objects degraded
(4.922%), 19 pgs degraded, 19 pgs undersized
8 pgs not deep-scrubbed in time
services:
mon: 1 daemons, quorum gedasvl02 (age 2w)
mgr: gedasvl02.vqswxg(active, since 2w), standbys: gedaopl02.yrwzqh
mds: cephfs:1 {0=cephfs.gedaopl01.zjuhem=up:active} 1 up:standby
osd: 3 osds: 3 up (since 9m), 3 in (since 9m); 18 remapped pgs
task status:
scrub status:
mds.cephfs.gedaopl01.zjuhem: idle
data:
pools: 7 pools, 225 pgs
objects: 13.14k objects, 77 GiB
usage: 214 GiB used, 457 GiB / 671 GiB avail
pgs: 1941/39432 objects degraded (4.922%)
206 active+clean
18 active+undersized+degraded+remapped+backfill_wait
1 active+undersized+degraded+remapped+backfilling
io:
recovery: 105 MiB/s, 25 objects/s
Many thanks for your help. This was an excellent "Recovery training" :)
Yes, certainly the best way (and moment) to break Ceph and gain
experience ;-).
Gr. Stefan