<div dir="ltr"><div>Thanks for your response Tim. If you would like SSH access to these boxes let me know, we can work something out privately. Thanks!<br><br></div><div>Update from yesterday:<br></div><div>It looks like 2 of the 4 nodes in our cluster have finally shut down, all channels are now gone. Another node in the cluster hangs on<br>
</div><div>&gt; sudo rabbitmqctl status<br><br></div><div>and the final node in the cluster appears to be running just fine. It however sees the unresponsive node in the cluster status as a running node, as does the web UI.<br>
</div><div><br><br><b>When you upgraded your cluster, what RabbitMQ version did you upgrade 
from and to, and did you upgrade Erlang as well and if so, which 
versions were involved?<br></b></div>- we upgraded from 3.0.4 to 3.1.0, we did not upgrade Erlang it was/is at version R15B03. We did however install it via RPM with the --nodeps flag because it did not detect the Erlang dependency correctly. We had previously installed Erlang:<br>
<br>esl-erlang.x86_64��� R15B03-2���������� @erlang-solutions <br><br><b><br>What happens if you start up Erlang by itself, using `erl -sname test` - do you still see all those screwy warnings? </b><br><div>All 4 of the nodes can run this without issue as my user, when I sudo su to rabbitmq user I get errors on 2 of the 4 nodes as such:<br>
<br>{error_logger,{{2013,5,17},{8,32,39}},std_error,&quot;File operation error: eacces. Target: .. Function: read_file_info. Process: code_server.&quot;}<br>{error_logger,{{2013,5,17},{8,32,39}},std_error,&quot;File operation error: eacces. Target: ./beam_lib.beam. Function: get_file. Process: code_server.&quot;}<br>
{error_logger,{{2013,5,17},{8,32,39}},std_error,&quot;File operation error: eacces. Target: ./ram_file.beam. Function: get_file. Process: code_server.&quot;}<br>{error_logger,{{2013,5,17},{8,32,39}},std_error,&quot;File operation error: eacces. Target: ./standard_error.beam. Function: get_file. Process: code_server.&quot;}<br>
{error_logger,{{2013,5,17},{8,32,39}},std_error,&quot;File operation error: eacces. Target: ./supervisor_bridge.beam. Function: get_file. Process: code_server.&quot;}<br>{error_logger,{{2013,5,17},{8,32,39}},std_error,&quot;File operation error: eacces. Target: ./user_sup.beam. Function: get_file. Process: code_server.&quot;}<br>
{error_logger,{{2013,5,17},{8,32,39}},std_error,&quot;File operation error: eacces. Target: ./user_drv.beam. Function: get_file. Process: code_server.&quot;}<br>{error_logger,{{2013,5,17},{8,32,39}},std_error,&quot;File operation error: eacces. Target: ./group.beam. Function: get_file. Process: code_server.&quot;}<br>
{error_logger,{{2013,5,17},{8,32,39}},std_error,&quot;File operation error: eacces. Target: ./edlin.beam. Function: get_file. Process: code_server.&quot;}<br>{error_logger,{{2013,5,17},{8,32,39}},std_error,&quot;File operation error: eacces. Target: ./io_lib.beam. Function: get_file. Process: code_server.&quot;}<br>
{error_logger,{{2013,5,17},{8,32,39}},std_error,&quot;File operation error: eacces. Target: ./proplists.beam. Function: get_file. Process: code_server.&quot;}<br>{error_logger,{{2013,5,17},{8,32,39}},std_error,&quot;File operation error: eacces. Target: ./io_lib_format.beam. Function: get_file. Process: code_server.&quot;}<br>
Erlang R15B03 (erts-5.9.3.1) [source] [64-bit] [smp:16:16] [async-threads:0] [hipe] [kernel-poll:false]<br><br>{error_logger,{{2013,5,17},{8,32,39}},std_error,&quot;File operation error: eacces. Target: ./shell.beam. Function: get_file. Process: code_server.&quot;}<br>
{error_logger,{{2013,5,17},{8,32,39}},std_error,&quot;File operation error: eacces. Target: ./user_default.beam. Function: get_file. Process: code_server.&quot;}<br>{error_logger,{{2013,5,17},{8,32,39}},std_error,&quot;File operation error: eacces. Target: ./kernel_config.beam. Function: get_file. Process: code_server.&quot;}<br>
<br>=ERROR REPORT==== 17-May-2013::04:32:39 ===<br>File operation error: eacces. Target: .. Function: read_file_info. Process: code_server.<br><br><br>...............<br><br><br><br><br></div><div><div><div class="gmail_extra">
<br><br><br><div class="gmail_quote">On Fri, May 17, 2013 at 4:34 AM, Tim Watson <span dir="ltr">&lt;<a href="mailto:tim@rabbitmq.com" target="_blank">tim@rabbitmq.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div style="word-wrap:break-word">Some more questions as well...<div><br></div><div>When you upgraded your cluster, what RabbitMQ version did you upgrade from and to, and did you upgrade Erlang as well and if so, which versions were involved?</div>
<div><br></div><div>Cheers,</div><div>Tim</div><div><div class="h5"><div><br><div><div>On 16 May 2013, at 21:54, Tim Watson wrote:</div><br><blockquote type="cite"><div style="word-wrap:break-word">Hi Eric,<div><br></div>
<div><blockquote type="cite"><div dir="ltr"><div><div>Thanks for the insight Tim. I ended up killing the the process before receiving your email so I was unable to take advantage of your pro tips. We subsequently upgraded our cluster to 3.1.0 on Erlang R15B03, and have run into a slightly different problem. This appears to be unrelated, but I did use your tips to gather as much information as possible.<br>
<br></div>Scenario:<br></div><div>A producer is sending messages to rabbit faster than they can be routed so the connection goes under flow control. The flow control lasts long enough so that our load balancer severs the connection. Before we understood that the LB was our problem we would just retry socket write up to 10 times before throwing an exception. In the end, our cluster now has 0 connections yet it still has nearly 4000 channels (screen grab attached). Also, now I am unable to stop_app on any node in the cluster without it hanging for, at this point, over an hour.<br>
</div></div></blockquote></div><div><br></div><div>That looks and sounds like a seriously unhappy Rabbit - I&#39;m very concerned, especially about those open channels, but it&#39;s quite late, so I&#39;ll need to get into this properly in the morning. For the time being though, it looks a lot like something has gone horribly wrong with your Erlang installation. What happens if you start up Erlang by itself, using `erl -sname test` - do you still see all those screwy warnings? It seems as though the emulator&#39;s code server is unable to read from the file system - this could be due to a change in permissions somewhere on the host&#39;s file system, *or* it could be that you&#39;re running the `erl -sname debug -remsh rabbit@rabbit-box` command from a user account with insufficient permissions.</div>
<div><br></div><div>Can you run `lsof` and let us know what the hosts use of file descriptors looks like please. A Rabbit should never have open channels that aren&#39;t tied to a connection. It looks to me like your rabbit is stuck either starting up or shutting down - that&#39;s why the application controller isn&#39;t responding to calls (or is timing out). In fact, general stats about the state of your OS would be really useful - file descriptor usage, current disk io, cpu and memory use would all help. If you&#39;ve got historic data about these too, especially around the time of your traffic spike, all the better.</div>
<div><br></div><div>It would be *very* helpful if you&#39;d be able to grant us ssh access to this machine - we might be able to sign some legal stuff if that helps. Without access to the machine, the diagnostic process is going to involve a fair bit of to-ing and fro-ing. We could make use of IM/IRC if that helps too. Drop me a note and let me know what&#39;s likely to work best for you.</div>
<div><br></div><div>To clarify</div><div><br></div><div><blockquote type="cite"><div dir="ltr"><div>Questions:<br></div><div>1. Should rabbit maintain channels without active connections? If not, has anyone run into this before?<br>
</div></div></blockquote><div><br></div><div>No, never. I&#39;ve not seen this one before, but I&#39;ll do some archeology in our bug tracker and the mailing list to see if there&#39;s anything that might help.</div><br><blockquote type="cite">
<div dir="ltr"><div>2. Is there any way to force kill these channels?<br></div></div></blockquote><div><br></div><div>We might be able to find a way to do that, but TBH the state your rabbit is in, I think it&#39;ll need to be killed. BUT PLEASE don&#39;t do that. It&#39;s really important that we understand how your system got into this state, because it represents a really nasty bug that we should fix asap, and having a running Rabbit in this state represents our best chance at understanding what&#39;s going on..</div>
<br><blockquote type="cite"><div dir="ltr"><div>3. Is it a good practice for consumers to connect to rabbit via a load balancer, or should that be for producers only? Are there any recommended timeout settings?<br></div></div>
</blockquote></div><div><div dir="ltr"><div><br></div></div></div><div>You should be able to use a LB for either kind of client, the choice of timeout should be application and infrastructure dependent - i.e., whatever makes sense for your use case - and doing so should *not* get you into this state, ever. We *will* find out what&#39;s gone on here and fix it, asap. The *only* caveat here is that, if something catastrophic has gone wrong with our host machine (e.g., the file system has bombed out, or something like that) then it might be that no application would stand any chance of surviving intact, but we need to understand what&#39;s gone on here either way.�</div>
<div><br></div><div>Cheers,</div><div>Tim</div><div><br><div><div>On 16 May 2013, at 20:09, Eric Berg wrote:</div><br><blockquote type="cite"><div dir="ltr"><div><div><br></div></div><div>Here are the results of some commands on the shell to the broker:<br>

<br><br>bash-4.1$ erl -sname debug -remsh rabbit@rabbit-box<br>{error_logger,{{2013,5,16},{14,44,36}},std_error,&quot;File operation error: eacces. Target: .. Function: read_file_info. Process: code_server.&quot;}<br>{error_logger,{{2013,5,16},{14,44,37}},std_error,&quot;File operation error: eacces. Target: ./beam_lib.beam. Function: get_file. Process: code_server.&quot;}<br>

{error_logger,{{2013,5,16},{14,44,37}},std_error,&quot;File operation error: eacces. Target: ./ram_file.beam. Function: get_file. Process: code_server.&quot;}<br>{error_logger,{{2013,5,16},{14,44,37}},std_error,&quot;File operation error: eacces. Target: ./standard_error.beam. Function: get_file. Process: code_server.&quot;}<br>

{error_logger,{{2013,5,16},{14,44,37}},std_error,&quot;File operation error: eacces. Target: ./supervisor_bridge.beam. Function: get_file. Process: code_server.&quot;}<br>{error_logger,{{2013,5,16},{14,44,37}},std_error,&quot;File operation error: eacces. Target: ./user_sup.beam. Function: get_file. Process: code_server.&quot;}<br>

{error_logger,{{2013,5,16},{14,44,37}},std_error,&quot;File operation error: eacces. Target: ./user_drv.beam. Function: get_file. Process: code_server.&quot;}<br>{error_logger,{{2013,5,16},{14,44,37}},std_error,&quot;File operation error: eacces. Target: ./group.beam. Function: get_file. Process: code_server.&quot;}<br>

{error_logger,{{2013,5,16},{14,44,37}},std_error,&quot;File operation error: eacces. Target: ./edlin.beam. Function: get_file. Process: code_server.&quot;}<br>{error_logger,{{2013,5,16},{14,44,37}},std_error,&quot;File operation error: eacces. Target: ./io_lib.beam. Function: get_file. Process: code_server.&quot;}<br>

{error_logger,{{2013,5,16},{14,44,37}},std_error,&quot;File operation error: eacces. Target: ./proplists.beam. Function: get_file. Process: code_server.&quot;}<br>{error_logger,{{2013,5,16},{14,44,37}},std_error,&quot;File operation error: eacces. Target: ./io_lib_format.beam. Function: get_file. Process: code_server.&quot;}<br>

Erlang R15B03 (erts-5.9.3.1) [source] [64-bit] [smp:16:16] [async-threads:0] [hipe] [kernel-poll:false]<br><br>{error_logger,{{2013,5,16},{14,44,37}},std_error,&quot;File operation error: eacces. Target: ./net.beam. Function: get_file. Process: code_server.&quot;}<br>

{error_logger,{{2013,5,16},{14,44,37}},std_error,&quot;File operation error: eacces. Target: ./inet_gethost_native.beam. Function: get_file. Process: code_server.&quot;}<br>{error_logger,{{2013,5,16},{14,44,37}},std_error,&quot;File operation error: eacces. Target: ./kernel_config.beam. Function: get_file. Process: code_server.&quot;}<br>

<br>=ERROR REPORT==== 16-May-2013::10:44:36 ===<br>File operation error: eacces. Target: .. Function: read_file_info. Process: code_server.<br><br>=ERROR REPORT==== 16-May-2013::10:44:37 ===<br>File operation error: eacces. Target: ./beam_lib.beam. Function: get_file. Process: code_server.<br>

<br>=ERROR REPORT==== 16-May-2013::10:44:37 ===<br>File operation error: eacces. Target: ./ram_file.beam. Function: get_file. Process: code_server.<br><br>=ERROR REPORT==== 16-May-2013::10:44:37 ===<br>File operation error: eacces. Target: ./standard_error.beam. Function: get_file. Process: code_server.<br>

<br>=ERROR REPORT==== 16-May-2013::10:44:37 ===<br>File operation error: eacces. Target: ./supervisor_bridge.beam. Function: get_file. Process: code_server.<br><br>=ERROR REPORT==== 16-May-2013::10:44:37 ===<br>File operation error: eacces. Target: ./user_sup.beam. Function: get_file. Process: code_server.<br>

<br>=ERROR REPORT==== 16-May-2013::10:44:37 ===<br>File operation error: eacces. Target: ./user_drv.beam. Function: get_file. Process: code_server.<br><br>=ERROR REPORT==== 16-May-2013::10:44:37 ===<br>File operation error: eacces. Target: ./group.beam. Function: get_file. Process: code_server.<br>

<br>=ERROR REPORT==== 16-May-2013::10:44:37 ===<br>File operation error: eacces. Target: ./edlin.beam. Function: get_file. Process: code_server.<br><br>=ERROR REPORT==== 16-May-2013::10:44:37 ===<br>{lost_messages,6}<br>
<br>
=ERROR REPORT==== 16-May-2013::14:44:37 ===<br>File operation error: eacces. Target: ./error_logger_tty_h.beam. Function: get_file. Process: code_server.<br><br>=ERROR REPORT==== 16-May-2013::14:44:37 ===<br>File operation error: eacces. Target: ./calendar.beam. Function: get_file. Process: code_server.<br>

<br>=ERROR REPORT==== 16-May-2013::14:44:37 ===<br>File operation error: eacces. Target: ./io_lib_pretty.beam. Function: get_file. Process: code_server.<br><br>=ERROR REPORT==== 16-May-2013::14:44:37 ===<br>File operation error: eacces. Target: ./io.beam. Function: get_file. Process: code_server.<br>

<br>=ERROR REPORT==== 16-May-2013::14:44:37 ===<br>File operation error: eacces. Target: ./erl_scan.beam. Function: get_file. Process: code_server.<br><br>=ERROR REPORT==== 16-May-2013::14:44:37 ===<br>File operation error: eacces. Target: ./c.beam. Function: get_file. Process: code_server.<br>

<br>=ERROR REPORT==== 16-May-2013::14:44:37 ===<br>File operation error: eacces. Target: ./erl_eval.beam. Function: get_file. Process: code_server.<br><br>=ERROR REPORT==== 16-May-2013::14:44:37 ===<br>File operation error: eacces. Target: ./orddict.beam. Function: get_file. Process: code_server.<br>

<br>=ERROR REPORT==== 16-May-2013::14:44:37 ===<br>File operation error: eacces. Target: ./file_io_server.beam. Function: get_file. Process: code_server.<br><br>=ERROR REPORT==== 16-May-2013::14:44:37 ===<br>File operation error: eacces. Target: ./erl_posix_msg.beam. Function: get_file. Process: code_server.<br>

<br>=ERROR REPORT==== 16-May-2013::14:44:37 ===<br>file:path_eval([&quot;.&quot;,&quot;/var/lib/rabbitmq&quot;],&quot;.erlang&quot;): permission denied<br><br>=ERROR REPORT==== 16-May-2013::14:44:37 ===<br>File operation error: eacces. Target: ./dist_util.beam. Function: get_file. Process: code_server.<br>

Eshell V5.9.3.1� (abort with ^G)<br><br></div><div><br><br><br>-------------------------------------------------<br><br>(rabbit@rabbit-box)1&gt; whereis(rabbit).<br>&lt;0.251.0&gt;<br><br><br>-------------------------------------------------<br>

<br>(rabbit@rabbit-box)2&gt; application:loaded_applications().<br>[{public_key,&quot;Public key infrastructure&quot;,&quot;0.17&quot;},<br>�{rabbitmq_management_agent,&quot;RabbitMQ Management Agent&quot;,<br>��������������������������� &quot;3.1.0&quot;},<br>

�{os_mon,&quot;CPO� CXC 138 46&quot;,&quot;2.2.10&quot;},<br>�{amqp_client,&quot;RabbitMQ AMQP Client&quot;,&quot;3.1.0&quot;},<br>�{mnesia,&quot;MNESIA� CXC 138 12&quot;,&quot;4.7.1&quot;},<br>�{rabbitmq_shovel,&quot;Data Shovel for RabbitMQ&quot;,&quot;3.1.0&quot;},<br>

�{inets,&quot;INETS� CXC 138 49&quot;,&quot;5.9.2&quot;},<br>�{rabbitmq_federation,&quot;RabbitMQ Federation&quot;,&quot;3.1.0&quot;},<br>�{rabbitmq_web_dispatch,&quot;RabbitMQ Web Dispatcher&quot;,&quot;3.1.0&quot;},<br>

�{rabbitmq_federation_management,&quot;RabbitMQ Federation Management&quot;,<br>�������������������������������� &quot;3.1.0&quot;},<br>�{rabbitmq_management_visualiser,&quot;RabbitMQ Visualiser&quot;,<br>�������������������������������� &quot;3.1.0&quot;},<br>

�{kernel,&quot;ERTS� CXC 138 10&quot;,&quot;2.15.3&quot;},<br>�{crypto,&quot;CRYPTO version 2&quot;,&quot;2.2&quot;},<br>�{ssl,&quot;Erlang/OTP SSL application&quot;,&quot;5.1.2&quot;},<br>�{sasl,&quot;SASL� CXC 138 11&quot;,&quot;2.2.1&quot;},<br>

�{rabbitmq_management,&quot;RabbitMQ Management Console&quot;,&quot;3.1.0&quot;},<br>�{mochiweb,&quot;MochiMedia Web Server&quot;,<br>���������� &quot;2.3.1-rmq3.1.0-gitd541e9a&quot;},<br>�{xmerl,&quot;XML parser&quot;,&quot;1.3.2&quot;},<br>

�{rabbit,&quot;RabbitMQ&quot;,&quot;3.1.0&quot;},<br>�{stdlib,&quot;ERTS� CXC 138 10&quot;,&quot;1.18.3&quot;},<br>�{webmachine,&quot;webmachine&quot;,&quot;1.9.1-rmq3.1.0-git52e62bc&quot;}]<br><br><br>------------------------------------------------------------------------------------<br>

<br><br>(rabbit@rabbit-box)3&gt; application:which_applications(). <br>** exception exit: {timeout,{gen_server,call,<br>��������������������������������������� [application_controller,which_applications]}}<br>���� in function� gen_server:call/2 (gen_server.erl, line 180)<br>

<br><br>-----------------------------------------------------------------------------------<br><br>(rabbit@rabbit-box)4&gt; rabbit:stop().<br><br><br></div><div>-- This hangs indefinitely <br></div><div><br><br>------------------------------------------------------------------------------------<br>

<br></div><div>Perms on /var/lib/rabbitmq<br>drwxr-xr-x� 3 rabbitmq rabbitmq 4096 May� 1 07:15 rabbitmq<br><br><br><br><br></div><div>Thanks Tim et al.<br></div><div><br><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">

On Thu, May 9, 2013 at 10:00 AM, Tim Watson <span dir="ltr">&lt;<a href="mailto:tim@rabbitmq.com" target="_blank">tim@rabbitmq.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">

<div style="word-wrap:break-word">Hi,<div><br><div><div>On 8 May 2013, at 18:22, Eric Berg wrote:</div><br><blockquote type="cite"><div dir="ltr">I have ready through many of these nodedown error emails and of course none of them seem to be exactly what I am experiencing.<div>

<br></div><div>I have a 4 node cluster, and one of the nodes went offline according to the cluster. This box has the following in the sasl log:</div>
<div><br></div><div><div>=SUPERVISOR REPORT==== 7-May-2013::14:37:22 ===</div><div>� � �Supervisor: {&lt;0.11197.1096&gt;,</div><div>� � � � � � � � � � � � � � � � � � � � � �rabbit_channel_sup_sup}</div><div>
� � �Context: � �shutdown_error</div><div>� � �Reason: � � noproc</div><div>� � �Offender: � [{pid,&lt;0.11199.1096&gt;},</div><div>� � � � � � � � � {name,channel_sup},</div><div>� � � � � � � � � {mfa,{rabbit_channel_sup,start_link,[]}},</div>


<div>� � � � � � � � � {restart_type,temporary},</div><div>� � � � � � � � � {shutdown,infinity},</div><div>� � � � � � � � � {child_type,supervisor}]</div><div><br></div></div></div></blockquote><div><br></div><div>This simply indicates that and error occurred whilst a supervised process was shutting down. It&#39;s not indicative of the whole node going down - Erlang allows processes to crash and be restarted whilst the system is running.</div>

<br><blockquote type="cite"><div dir="ltr"><div><div><b>Yet in the regular rabbit log i can see that it was still accepting connections up until 2:22AM the next day:</b></div>
<div><br></div><div>(last log entry)</div><div><div>=INFO REPORT==== 8-May-2013::02:22:26 ===</div><div>closing AMQP connection &lt;0.18267.1145&gt; (IPADDRESS:PORT -&gt;�IPADDRESS:PORT)</div><div><br></div></div></div></div>

</blockquote><div><br></div><div>So clearly that node didn&#39;t actually go offline. The &#39;nodedown&#39; message in the other clustered broker&#39;s logs does not necessarily mean that the node in question crashed; This could, for example, be indicative of a net-split or other connectivity failure.�</div>

<br><blockquote type="cite"><div dir="ltr"><div><div>
<div><b>Running rabbitmqctl status returns:</b></div><div><br></div><div><div>[root@rabbit-box�rabbitmq]# rabbitmqctl status</div><div>Status of node &#39;rabbit@rabbit-box&#39; ...</div><div>Error: unable to connect to node &#39;rabbit@rabbit-box&#39;: nodedown</div>


<div><br></div><div>DIAGNOSTICS</div><div>===========</div><div><br></div><div>nodes in question: [&#39;rabbit@rabbit-box&#39;]</div><div><br></div><div>hosts, their running nodes and ports:</div><div>-�rabbit-box: [{rabbit,13957},{rabbitmqctl2301,16508}]</div>


<div><br></div><div>current node details:</div><div>- node name: &#39;rabbitmqctl2301@rabbit-box&#39;</div><div>- home dir: /var/lib/rabbitmq</div><div>- cookie hash: qQwyFW90ZNbbrFvX1AtrxQ==</div></div></div></div></div>

</blockquote><div><br></div><div>Have you tried running this using `sudo&#39; instead of as root? Is the rabbitmq user&#39;s account and home folder in a consistent state? The security cookie used for inter-node communications, which includes communication between the temporary `rabbitmqctl&#39; node and the broker, has to be the same for all the peers.</div>

<br><blockquote type="cite"><div dir="ltr"><div><div><div><div>A couple of notes:</div><div>- Looking for a process run by rabbit show that it appears to still be running</div></div></div></div></div></blockquote><div><br>

</div><div>Yes - as I said, there&#39;s no indication that this node actually died from what you&#39;ve said. However `rabbitmqctl` should be able to connect to rabbit@rabbit-box at the very least.�</div><br><blockquote type="cite">

<div dir="ltr"><div><div><div><div>- Erlang cookie is the same on all nodes of the cluster, the cookie hash is the same as well</div></div></div></div></div></blockquote><div><br></div><div>If it&#39;s not the cookies then....</div>

<br><blockquote type="cite"><div dir="ltr"><div><div><div><div>- A traffic spike occurred right around the time of the last entry in the rabbit log</div></div></div></div></div></blockquote><div><br></div><div>It sounds like this could be a potential culprit. Can you provide any more information about what happened? It could be that whilst the network was saturated, the node in question got disconnected from the other nodes in the cluster because it exceeded the &quot;net tick time&quot; and subsequently things have started to go wrong. That shouldn&#39;t happen, viz the node should be able to re-establish connectivity, but it&#39;s possible that something&#39;s gone wrong here.</div>

<div><br></div><div>What that doesn&#39;t explain is why you can&#39;t connect from rabbitmqctl. If you `su rabbitmq&#39;, can you then run `erl -sname debug -remsh rabbit@rabbit-box&#39; to establish a shell into the running broker? If that does work, then you can stop the rabbit application and then the node, as follows:</div>

<div><br></div><div>&gt; rabbit:stop().</div><div>ok</div><div>&gt; init:stop().</div><div><br></div><div>But before you do, it might be worth evaluating a couple of other things that might help us identify what&#39;s going on:</div>

<div><br></div><div>(rabbit@iske)1&gt; whereis(rabbit).</div><div>&lt;0.152.0&gt;</div><div>(rabbit@iske)2&gt; application:loaded_applications().</div><div>[{os_mon,&quot;CPO �CXC 138 46&quot;,&quot;2.2.9&quot;},</div><div>

�{rabbitmq_management_agent,&quot;RabbitMQ Management Agent&quot;,</div><div>� � � � � � � � � � � � � � &quot;0.0.0&quot;},</div><div>�{amqp_client,&quot;RabbitMQ AMQP Client&quot;,&quot;0.0.0&quot;},</div><div>�etc ...</div>

<div>�]</div><div>(rabbit@iske)3&gt; application:which_applications().�</div><div>[{rabbitmq_shovel_management,&quot;Shovel Status&quot;,&quot;0.0.0&quot;},</div><div>�etc ...</div><div>]</div><div>�</div><div>If during any of these you get stuck, CTRL-C (and press the key for &#39;abort&#39;) should get you back out again without incident.</div>

<div><br></div><br><blockquote type="cite"><div dir="ltr"><div><div><div><div>- I can find no other errors in any logs that relate to rabbit or erlang</div><div>- Up until this point the cluster has been running fine for over 40 days.</div>

</div></div></div></div></blockquote><blockquote type="cite"><div dir="ltr"><div><div><div><div>-�telnet IP_ADDRESS 5672 times out</div></div></div></div></div></blockquote><div><br></div><div>So the broker is no longer accepting new AMQP connections then. Something&#39;s clearly quite wrong with this node.</div>

<br><blockquote type="cite"><div dir="ltr"><div><div><div><div>- I have not restarted the box, erlang node, or entire rabbitmq-server</div><div><br></div><div>Is there anywhere else I can go looking for errors? I am about to start killing processs, but Im not sure that will solve anything.</div>


<div><br></div></div></div></div></div></blockquote><div><br></div><div>Did you do that in the end? If not, I would really like to get to the bottom of what&#39;s wrong with this node. I don&#39;t suppose it would be possible for you to give us access to this machine would it? If necessary, we may be able to get some kind of confidentiality agreement signed if that&#39;d help.</div>

<div><br></div><div>Cheers,</div><div><br></div><div>Tim Watson</div><div>Staff Engineer</div><div>RabbitMQ</div><div><br></div><div><br></div><div><br></div></div></div></div><br>_______________________________________________<br>


rabbitmq-discuss mailing list<br>
<a href="mailto:rabbitmq-discuss@lists.rabbitmq.com" target="_blank">rabbitmq-discuss@lists.rabbitmq.com</a><br>
<a href="https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss" target="_blank">https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss</a><br>
<br></blockquote></div><br></div>
<span>&lt;rabbit-manychannels.png&gt;</span>_______________________________________________<br>rabbitmq-discuss mailing list<br><a href="mailto:rabbitmq-discuss@lists.rabbitmq.com" target="_blank">rabbitmq-discuss@lists.rabbitmq.com</a><br>
<a href="https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss" target="_blank">https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss</a><br></blockquote></div><br></div></div>_______________________________________________<br>
rabbitmq-discuss mailing list<br><a href="mailto:rabbitmq-discuss@lists.rabbitmq.com" target="_blank">rabbitmq-discuss@lists.rabbitmq.com</a><br><a href="https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss" target="_blank">https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss</a><br>
</blockquote></div><br></div></div></div></div><br>_______________________________________________<br>
rabbitmq-discuss mailing list<br>
<a href="mailto:rabbitmq-discuss@lists.rabbitmq.com">rabbitmq-discuss@lists.rabbitmq.com</a><br>
<a href="https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss" target="_blank">https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss</a><br>
<br></blockquote></div><br></div></div></div></div>