This doesn't look familiar. Are you able to enable a higher log level so that if it happens again we'll have more info? debug mon = 20 debug ms = 1 Thanks! sage On Fri, 16 Oct 2015, Dan van der Ster wrote: > 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 > > _______________________________________________ ceph-users mailing list ceph-users@xxxxxxxxxxxxxx http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com
 |