Hello,


Today I had a single RabbitMQ instance crash. The server was running
RabbitMQ 3.0.1 on R15B02 and was not in a cluster. There was nothing in the
shutdown log.


The only indication of trouble was in /var/log/messages


Jan 29 11:51:41 egressqueue01 kernel: beam.smp[9371]: segfault at
fffffffffffffffe ip 00000000005419ba sp 00007f476bccad00 error 4 in
beam.smp[400000+214000]


Issuing a "/etc/init.d/rabbitmq start" brought the service back up, and
after a little while it started passing messages again.


Any idea where I should be looking?


Thanks so much!


-D
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20130129/a8e633c3/attachment.htm>

Search Discussions

  • Emile Joubert at Jan 29, 2013 at 5:33 pm
    Hi Dave,

    On 29/01/13 17:08, Dave Seltzer wrote:
    Jan 29 11:51:41 egressqueue01 kernel: beam.smp[9371]: segfault at
    fffffffffffffffe ip 00000000005419ba sp 00007f476bccad00 error 4 in
    beam.smp[400000+214000]

    Issuing a "/etc/init.d/rabbitmq start" brought the service back up, and
    after a little while it started passing messages again.

    That should not be taken lightly. Segfaults in the VM should not happen
    with a default installation. If you are running or developing a plugin
    with code that runs in the VM then segfaults could occur as a result.
    They are also more likely when you enable HiPE. If you have HiPE enabled
    then turn it off and see if that makes a difference. In some cases
    hardware errors can be to blame, so make sure the server hardware is in
    good shape.


    If the segfault produced a core file then it should be possible to work
    out where the error occurred. It will most likely be produced in the
    working directory of the account that runs the broker. The information
    from the core file can be reported to the erlang-bugs mailing list, or
    we can forward it on your behalf. If the Erlang VM was not compiled with
    debugging information then there is probably little information to be
    gleaned from the core file. If the error is reproducible then it may be
    worth getting hold of an Erlang VM with debugging symbols.


    In some cases a erl_crash.dump file will be produced when the VM
    crashes. If you find one (probably also in the working directory of the
    account that runs the broker) then please compress and send it to us.






    -Emile
  • Dave Seltzer at Jan 29, 2013 at 5:40 pm
    Thanks Emile,


    I'm not sure what HiPE is, and I haven't been running any unusual plugins.
    There was an erl_crash.dump file, but it's dated from the early this month,
    so it may be from a previous crash.


    The server is running Centos 6.3 on XenServer. I think I need to look at
    the Linux VM itself and see if there's something which could be causing it
    to be unstable.


    Thanks for your advice!


    -D




    On Tue, Jan 29, 2013 at 12:33 PM, Emile Joubert wrote:

    Hi Dave,
    On 29/01/13 17:08, Dave Seltzer wrote:
    Jan 29 11:51:41 egressqueue01 kernel: beam.smp[9371]: segfault at
    fffffffffffffffe ip 00000000005419ba sp 00007f476bccad00 error 4 in
    beam.smp[400000+214000]

    Issuing a "/etc/init.d/rabbitmq start" brought the service back up, and
    after a little while it started passing messages again.
    That should not be taken lightly. Segfaults in the VM should not happen
    with a default installation. If you are running or developing a plugin
    with code that runs in the VM then segfaults could occur as a result.
    They are also more likely when you enable HiPE. If you have HiPE enabled
    then turn it off and see if that makes a difference. In some cases
    hardware errors can be to blame, so make sure the server hardware is in
    good shape.

    If the segfault produced a core file then it should be possible to work
    out where the error occurred. It will most likely be produced in the
    working directory of the account that runs the broker. The information
    from the core file can be reported to the erlang-bugs mailing list, or
    we can forward it on your behalf. If the Erlang VM was not compiled with
    debugging information then there is probably little information to be
    gleaned from the core file. If the error is reproducible then it may be
    worth getting hold of an Erlang VM with debugging symbols.

    In some cases a erl_crash.dump file will be produced when the VM
    crashes. If you find one (probably also in the working directory of the
    account that runs the broker) then please compress and send it to us.



    -Emile


    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: <http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20130129/c3323469/attachment.htm>

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouprabbitmq-discuss @
categoriesrabbitmq
postedJan 29, '13 at 5:08p
activeJan 29, '13 at 5:40p
posts3
users2
websiterabbitmq.com
irc#rabbitmq

2 users in discussion

Dave Seltzer: 2 posts Emile Joubert: 1 post

People

Translate

site design / logo © 2017 Grokbase