v3.3.4 -- meaning of 'brutal_kill' in sasl.log
230 views
Skip to first unread message
Tony
Jul 30, 2015, 1:01:37 PM7/30/15
to rabbitmq-users
We occasionally see these in our RabbitMQ server v3.3.4 on Windows SASL.log file. Are they significant? What do they indicate? They seem to come in two varieties "Reason: shutdown" and "Reason: badarg...".
=SUPERVISOR REPORT==== 30-Jul-2015::16:38:18 === Supervisor: {<0.6233.229>,amqp_channel_sup_sup} Context: shutdown_error Reason: shutdown Offender: [{nb_children,1}, {name,channel_sup}, {mfargs, {amqp_channel_sup,start_link, [direct,<0.6147.229>, <<"<rabbit@SERVERNAME03.1.6147.229>">>]}}, {restart_type,temporary}, {shutdown,brutal_kill}, {child_type,supervisor}]
=SUPERVISOR REPORT==== 30-Jul-2015::15:16:12 === Supervisor: {<0.1096.0>,cowboy_requests_sup} Context: child_terminated Reason: {badarg, [{cowboy_http,urldecode,3,[]}, {cowboy_dispatcher,'-do_split_path/3-lc$^0/1-0-',2,[]}, {cowboy_dispatcher,split_path,2,[]}, {cowboy_http_protocol,request,2,[]}]} Offender: [{pid,<0.24019.228>}, {name,cowboy_requests_sup}, {mfargs,{cowboy_requests_sup,start_request,undefined}}, {restart_type,temporary}, {shutdown,brutal_kill}, {child_type,worker}]
=SUPERVISOR REPORT==== 30-Jul-2015::16:38:18 === Supervisor: {<0.6233.229>,amqp_channel_sup_sup} Context: shutdown_error Reason: shutdown Offender: [{nb_children,1}, {name,channel_sup}, {mfargs, {amqp_channel_sup,start_link, [direct,<0.6147.229>, <<"<rabbit@SERVERNAME03.1.6147.229>">>]}}, {restart_type,temporary}, {shutdown,brutal_kill}, {child_type,supervisor}]
=SUPERVISOR REPORT==== 30-Jul-2015::15:16:12 === Supervisor: {<0.1096.0>,cowboy_requests_sup} Context: child_terminated Reason: {badarg, [{cowboy_http,urldecode,3,[]}, {cowboy_dispatcher,'-do_split_path/3-lc$^0/1-0-',2,[]}, {cowboy_dispatcher,split_path,2,[]}, {cowboy_http_protocol,request,2,[]}]} Offender: [{pid,<0.24019.228>}, {name,cowboy_requests_sup}, {mfargs,{cowboy_requests_sup,start_request,undefined}}, {restart_type,temporary}, {shutdown,brutal_kill}, {child_type,worker}]
Michael Klishin
Jul 30, 2015, 1:28:02 PM7/30/15
to Tony, rabbitmq-users
On 30 July 2015 at 20:01:40, Tony (yellowja...@gmail.com) wrote:
> We occasionally see these in our RabbitMQ server v3.3.4 on Windows
> SASL.log file. Are they significant? What do they indicate?
> They seem to come in two varieties "Reason: shutdown" and "Reason:
> badarg...".
This means an Erlang process didn't terminate in an amount of time it was
> We occasionally see these in our RabbitMQ server v3.3.4 on Windows
> SASL.log file. Are they significant? What do they indicate?
> They seem to come in two varieties "Reason: shutdown" and "Reason:
> badarg...".
given to do so and forcefully killed (and possibly then restarted).
I'm not sure what mean lead to url decoding exceptions in Cowboy
(which is an HTTP and WebSocket server we use in rabbitmq-webstomp) but
our Cowboy version is outdated. We are starting the work on upgrading
it in the upcoming weeks.
--
MK
Staff Software Engineer, Pivotal/RabbitMQ
Tony
Jul 30, 2015, 2:08:34 PM7/30/15
to rabbitmq-users, mkli...@pivotal.io
Thanks for the quick response.
The errors were from v3.3.4, is Cowboy updated in v3.5.4?
The errors were from v3.3.4, is Cowboy updated in v3.5.4?
Michael Klishin
Jul 30, 2015, 2:10:08 PM7/30/15
to Tony, rabbitmq-users
On 30 July 2015 at 21:08:35, Tony (yellowja...@gmail.com) wrote:
> The errors were from v3.3.4, is Cowboy updated in v3.5.4?
No, 3.5.4 uses the same Cowboy version.
> The errors were from v3.3.4, is Cowboy updated in v3.5.4?
Tony
Sep 15, 2015, 1:33:39 PM9/15/15
to rabbitmq-users, yellowja...@gmail.com
I know, old thread...
What is the erlang "timeout" that is being exceeded that results in erlang terminating a request 'brutally'? Does the timeout vary from request to request? Is there some sort of erlang logging I could enable for a brief time that might provide more details?
We see ~100/day across our two clustered RabbitMQ severs v3.3.4 (Erlang v17.1) running on Windows. Maybe it is nothing, but I'd like to get a better understanding what might be happening.
What is the erlang "timeout" that is being exceeded that results in erlang terminating a request 'brutally'? Does the timeout vary from request to request? Is there some sort of erlang logging I could enable for a brief time that might provide more details?
We see ~100/day across our two clustered RabbitMQ severs v3.3.4 (Erlang v17.1) running on Windows. Maybe it is nothing, but I'd like to get a better understanding what might be happening.
On Thursday, July 30, 2015 at 1:28:02 PM UTC-4, Michael Klishin wrote:
Reply all
Reply to author
Forward
0 new messages