[rabbitmq-discuss] The rabbitmq-server stop command hangs

[Matthias Radestock]

On 28/11/12 11:29, Tim Watson wrote:
> Can you please confirm a couple of things for us: what plugins are
> enabled in your setup?

See Liz' earlier post:
<quote>
# rabbitmqctl eval 'app_utils:app_dependency_order([os_mon,
mnesia,rabbit] ++ rabbit_plugins:active(),true).'
[mnesia,mochiweb,amqp_client,webmachine,rabbitmq_mochiweb,os_mon,rabbit,
  rabbitmq_management_agent,rabbitmq_shovel,rabbitmq_management]
</quote>

I asked for this since it wasn't obvious to me
that the shutdown was hanging in the rabbit application.

If it isn't rabbit, then a prime candidate from the above list would be 
shovel.

Liz, are you using shovel? If so, what's the shovel configuration? And 
can you get the shovel status ("rabbitmqctl eval 
'rabbit_shovel_status:status().'") at the time the shutdown is hanging?

> The rabbit_reader seems to be attempting to consume data, and appears
> to be in 'start_connection' at shutdown time.

Nah, that's normal. start_connection calls the reader's main loop in a
non-tail position.

> The 'rabbit_reader:start_connection' trace looks a bit suspect too:
>
> stacktrace: [{rabbit_net,recv,2,[]}, {rabbit_reader,mainloop,2,[]},
> {rabbit_reader,start_connection,7,[]},
> {proc_lib,init_p_do_apply,3,[{file,"proc_lib.erl"},{line,227}]}]
>
> I wonder if a handshake has got stuck somehow? The rabbit_net:recv/2
> implementation does result in a blocking receive.

rabbit_net:recv is the normal place for the reader to sit when nothing
is happening. It has a catch-all 'Other' clause.

Regards,

Matthias.