Bug #5509
mon/Monitor.cc: 1395: FAILED assert(latest_monmap.epoch > 0)
0%
Description
2013-07-03T17:41:14.429 INFO:teuthology.task.ceph.mon.b.err:mon/Monitor.cc: In function 'void Monitor::sync_obtain_latest_monmap(ceph::bufferlist&)' thread a73d700 time 2013-07-04 00:41:27.818430 2013-07-03T17:41:14.429 INFO:teuthology.task.ceph.mon.b.err:mon/Monitor.cc: 1395: FAILED assert(latest_monmap.epoch > 0) 2013-07-03T17:41:14.609 INFO:teuthology.task.ceph.mon.b.err: ceph version 0.65-264-g3564e30 (3564e304e3f50642e4d9ff25e529d5fc60629093) 2013-07-03T17:41:14.609 INFO:teuthology.task.ceph.mon.b.err: 1: (Monitor::sync_obtain_latest_monmap(ceph::buffer::list&)+0xa6b) [0x55158b] 2013-07-03T17:41:14.609 INFO:teuthology.task.ceph.mon.b.err: 2: (Monitor::sync_store_init()+0x11d) [0x55177d] 2013-07-03T17:41:14.610 INFO:teuthology.task.ceph.mon.b.err: 3: (Monitor::sync_start(entity_inst_t&)+0xaf) [0x55199f] 2013-07-03T17:41:14.610 INFO:teuthology.task.ceph.mon.b.err: 4: (Monitor::handle_probe_reply(MMonProbe*)+0x658) [0x56dbd8] 2013-07-03T17:41:14.610 INFO:teuthology.task.ceph.mon.b.err: 5: (Monitor::handle_probe(MMonProbe*)+0x1bb) [0x56f04b] 2013-07-03T17:41:14.610 INFO:teuthology.task.ceph.mon.b.err: 6: (Monitor::_ms_dispatch(Message*)+0x3c7) [0x572cc7] 2013-07-03T17:41:14.610 INFO:teuthology.task.ceph.mon.b.err: 7: (Monitor::ms_dispatch(Message*)+0x32) [0x589be2] 2013-07-03T17:41:14.610 INFO:teuthology.task.ceph.mon.b.err: 8: (DispatchQueue::entry()+0x549) [0x7c5739] 2013-07-03T17:41:14.610 INFO:teuthology.task.ceph.mon.b.err: 9: (DispatchQueue::DispatchThread::entry()+0xd) [0x6ff82d] 2013-07-03T17:41:14.611 INFO:teuthology.task.ceph.mon.b.err: 10: (()+0x7e9a) [0x4e39e9a] 2013-07-03T17:41:14.611 INFO:teuthology.task.ceph.mon.b.err: 11: (clone()+0x6d) [0x686bccd] 2013-07-03T17:41:14.647 INFO:teuthology.task.ceph.mon.b.err: NOTE: a copy of the executable, or `objdump -rdS <executable>` is needed to interpret this. 2013-07-03T17:41:17.985 INFO:teuthology.task.ceph.mon.b.err:2013-07-04 00:41:28.284410 a73d700 -1 mon/Monitor.cc: In function 'void Monitor::sync_obtain_latest_monmap(ceph::bufferlist&)' thread a73d700 time 2013-07-04 00:41:27.818430 2013-07-03T17:41:17.985 INFO:teuthology.task.ceph.mon.b.err:mon/Monitor.cc: 1395: FAILED assert(latest_monmap.epoch > 0) ubuntu@teuthology:/var/lib/teuthworker/archive/teuthology-2013-07-03_15:34:36-rgw-master-testing-basic/53739$ cat orig.config.yaml kernel: kdb: true sha1: 109a5c78393ace94426e5a3fe710cd84333a92e9 machine_type: vps nuke-on-error: true overrides: admin_socket: branch: master ceph: conf: global: ms inject socket failures: 5000 mon: debug mon: 20 debug ms: 20 debug paxos: 20 osd: osd op thread timeout: 60 fs: btrfs log-whitelist: - slow request sha1: 3564e304e3f50642e4d9ff25e529d5fc60629093 valgrind: mds: - --tool=memcheck mon: - --tool=memcheck - --leak-check=full - --show-reachable=yes osd: - --tool=memcheck install: ceph: flavor: notcmalloc sha1: 3564e304e3f50642e4d9ff25e529d5fc60629093 s3tests: branch: master workunit: sha1: 3564e304e3f50642e4d9ff25e529d5fc60629093 roles: - - mon.a - mon.c - osd.0 - osd.1 - osd.2 - - mon.b - mds.a - osd.3 - osd.4 - osd.5 - client.0 tasks: - chef: null - clock.check: null - install: ceph: flavor: notcmalloc - ceph: null - rgw: client.0: valgrind: - --tool=memcheck - s3tests: client.0: rgw_server: client.0
Associated revisions
mon: remove bad assert about monmap version
It is possible to start a sync when our newest monmap is 0. Usually we see
e0 from probe, but that isn't always published as part of the very first
paxos transaction due to the way PaxosService::_active generates it's
first initial commit.
In any case, having e0 here is harmless.
Fixes: #5509
Signed-off-by: Sage Weil <sage@inktank.com>
Reviewed-by: Joao Eduardo Luis <joao.luis@inktank.com>
mon: remove bad assert about monmap version
It is possible to start a sync when our newest monmap is 0. Usually we see
e0 from probe, but that isn't always published as part of the very first
paxos transaction due to the way PaxosService::_active generates it's
first initial commit.
In any case, having e0 here is harmless.
Fixes: #5509
Signed-off-by: Sage Weil <sage@inktank.com>
Reviewed-by: Joao Eduardo Luis <joao.luis@inktank.com>
(cherry picked from commit 85a1d6cc5d3852c94d1287b566656c5b5024fa13)
History
#1 Updated by Sage Weil over 10 years ago
- Status changed from 12 to Fix Under Review
#2 Updated by Sage Weil over 10 years ago
- Status changed from Fix Under Review to Resolved