Hmm, that's strange. I didn't see anything in the tracker that looks related. Hopefully an expert can chime in... Cheers, Dan On Fri, Oct 16, 2015 at 1:38 PM, Richard Bade <hitrich@xxxxxxxxx> wrote: > Thanks for your quick response Dan, but no. All the ceph-mon.*.log files are > empty. > I did track this down in syslog though, in case it helps: > ceph-mon: 2015-10-16 21:25:00.117115 7f4c9f458700 -1 *** Caught signal > (Segmentation fault) **#012 in thread 7f4c9f458700#012#012 ceph version > 0.94.3 (95cefea9fd9ab740263bf8bb4796fd864d9afe2b)#012 1: /usr/bin/ceph-mon() > [0x928b05]#012 2: (()+0xfcb0) [0x7f4ca50e0cb0]#012 3: > (get_str_map_key(std::map<std::string, std::string, std::less<std::string>, > std::allocator<std::pair<std::string const, std::string> > > const&, > std::string const&, std::string const*)+0x37) [0x87d8e7]#012 4: > (LogMonitor::update_from_paxos(bool*)+0x801) [0x6846e1]#012 5: > (PaxosService::refresh(bool*)+0x3c6) [0x5dc326]#012 6: > (Monitor::refresh_from_paxos(bool*)+0x36b) [0x588aab]#012 7: > (Paxos::do_refresh()+0x4c) [0x5c465c]#012 8: > (Paxos::handle_commit(MMonPaxos*)+0x243) [0x5cb2d3]#012 9: > (Paxos::dispatch(PaxosServiceMessage*)+0x22b) [0x5d3fbb]#012 10: > (Monitor::dispatch(MonSession*, Message*, bool)+0x864) [0x5ab0d4]#012 11: > (Monitor::_ms_dispatch(Message*)+0x2c9) [0x5a8a19]#012 12: > (Monitor::ms_dispatch(Message*)+0x32) [0x5c3952]#012 13: > (Messenger::ms_deliver_dispatch(Message*)+0x77) [0x8ac987]#012 14: > (DispatchQueue::entry()+0x44a) [0x8a9b2a]#012 15: > (DispatchQueue::DispatchThread::entry()+0xd) [0x79e4ad]#012 16: (()+0x7e9a) > [0x7f4ca50d8e9a]#012 17: (clone()+0x6d) [0x7f4ca3dca38d]#012 NOTE: a copy of > the executable, or `objdump -rdS <executable>` is needed to interpret this. > > Regards, > Richard > > On 17 October 2015 at 00:33, Dan van der Ster <dan@xxxxxxxxxxxxxx> wrote: >> >> Hi, >> Is there a backtrace in /var/log/ceph/ceph-mon.*.log ? >> Cheers, Dan >> >> On Fri, Oct 16, 2015 at 12:46 PM, Richard Bade <hitrich@xxxxxxxxx> wrote: >> > Hi Everyone, >> > I upgraded our cluster to Hammer 0.94.3 a couple of days ago and today >> > we've >> > had one monitor crash twice and another one once. We have 3 monitors >> > total >> > and have been running Firefly 0.80.10 for quite some time without any >> > monitor issues. >> > When the monitor crashes it leaves a core file and a crash file in >> > /var/crash >> > I can't see anything obviously the same goolging about. >> > Has anyone seen anything like this? >> > Any suggestions? What other info would be useful to help track down the >> > issue. >> > >> > Regards, >> > Richard >> > >> > _______________________________________________ >> > ceph-users mailing list >> > ceph-users@xxxxxxxxxxxxxx >> > http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com >> > > > _______________________________________________ ceph-users mailing list ceph-users@xxxxxxxxxxxxxx http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com
 |