Details
Bug
Major
Description
We have the following beam.smp process that is failing to stop:
10745 /var/vcap/packages/erlang-20.0/lib/erlang/erts-9.0/bin/beam.smp -W w -A 128 -P 1048576 -t 5000000 -stbt db -zdbbl 32000 -K true -- -root /var/vcap/packages/erlang-20.0/lib/erlang -progname erl -- -home /home/vcap -- -pa /var/vcap/jobs/rabbitmq-server/packages/rabbitm
|
q-server/ebin -noshell -noinput -s rabbit boot -sname rabbit@rmq2-rmq-36-20170608 -boot start_sasl -config /var/vcap/jobs/rabbitmq-server/rabbitmq -kernel inet_default_connect_options [{nodelay,true}] -sasl errlog_type error -sasl sasl_error_logger false -rabbit error_logg
|
er {file,"/var/vcap/sys/log/rabbitmq-server/rabbit@rmq2-rmq-36-20170608.log"} -rabbit sasl_error_logger {file,"/var/vcap/sys/log/rabbitmq-server/rabbit@rmq2-rmq-36-20170608-sasl.log"} -rabbit enabled_plugins_file "/var/vcap/jobs/rabbitmq-server/packages/rabbitmq-server/etc
|
/rabbitmq/enabled_plugins" -rabbit plugins_dir "/var/vcap/jobs/rabbitmq-server/packages/rabbitmq-server/plugins" -rabbit plugins_expand_dir "/var/vcap/store/rabbitmq-server/mnesia/rabbit@rmq2-rmq-36-20170608-plugins-expand" -os_mon start_cpu_sup false -os_mon start_disksup
|
false -os_mon start_memsup false -mnesia dir "/var/vcap/store/rabbitmq-server/mnesia/rabbit@rmq2-rmq-36-20170608" -kernel inet_dist_listen_min 25672 -kernel inet_dist_listen_max 25672
|
We are running on:
4.4.0-81-generic #104~14.04.1-Ubuntu SMP Wed Jun 14 12:45:52 UTC 2017 x86_64 GNU/Linux
|
We cannot connect to it with a remote shell and the VM doesn't respond to `kill USR1` either. Attaching gdb log. We have isolated the host, e-mail us at gerhard@rabbitmq.com & jpedron@rabbitmq.com if you want access to it.
Activity
This is great, thanks for finding & fixing the bug 
Please update when the patch ships, will pass the info through the relevant RabbitMQ channels.
Gerhard Lazu
added a comment - - edited This is great, thanks for finding & fixing the bug
Please update when the patch ships, will pass the info through the relevant RabbitMQ channels. Thank you, John.
Will this be included in a future 19.3.x release? That's what many RabbitMQ users will be running for at least few more months.
michaelklishin
added a comment - Thank you, John.
Will this be included in a future 19.3.x release? That's what many RabbitMQ users will be running for at least few more months. Yes, it'll be included in 19.3.6.2
John Högberg
added a comment - Yes, it'll be included in 19.3.6.2 Hi again,
The latest patch for 20 (20.0.2) fixes this issue, as will tomorrow's patch for 19.
/John
John Högberg
added a comment - - edited Hi again,
The latest patch for 20 (20.0.2) fixes this issue, as will tomorrow's patch for 19.
/John Thanks! Deploying now 20.0.2 in our test environments, will report back if the issue re-surfaces.
Gerhard Lazu
added a comment - - edited Thanks! Deploying now 20.0.2 in our test environments, will report back if the issue re-surfaces. 
It's normal for the VM to be unresponsive during teardown, so it has probably started shutting down but is stuck waiting for a job to complete. Could you capture a core file for us?