Bug #1942
closed
Still not sure how the bad address made it into the map (or OSDBoot) message, but at least it won't crash now as of commit:a4642946b284c0b0fd85587e0c0b0bbf0ec4b0b4
- Status changed from New to 7
we now report a connection fault instead of asserting. and during initialization we check for bind() errors. afaics that would catch the initial problem. it's still a mystery how this bit two people on the v0.40 upgrade, though.
commit:dcceb8e835cbf40173c334de18bd68c2cf7f3716 add the osd_fsid to the OSDSuperblock message and reved the version. Old code happily decodes the new structure it doesn't understand, but stops before the new field. OSDSuperblock is embedded in the MOSDBoot, so old code will continue decoding the next fields (cluster_addr, hb_addr) starting with the new osd_fsid field, and the result is a zeroed out address. This made it into the osdmap, which triggered the impolite assert.
The new wip-encoding would have helped by just ignoring the new field.
The workaround is to restart the v0.40 monitors first, then restart the osds, so that old monitors don't see new OSDSuperblock encodings.
The monitor should reject a boot message if the addresses appear to be invalid.
- Status changed from 7 to Won't Fix
- Project changed from Ceph to Messengers
- Category deleted (
msgr)
- Target version deleted (
v0.41)
Also available in: Atom
PDF