Ok, debugging increased
ceph tell mon.[abc] injectargs --debug-mon 20
ceph tell mon.[abc] injectargs --debug-ms 1
Regards,
Richard
On 17 October 2015 at 01:38, Sage Weil <sage@xxxxxxxxxxxx> wrote:
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