[rabbitmq-discuss] Is it reasonable to stop a rabbitmq server by sending it a fatal signal?

Mon May 25 19:23:41 BST 2009

I think in general sending a SIGKILL (9) to a process should be done in
exceptional cases, and not as a part of a normal shutdown.  Typically
applications respond to SIGTERM (15) to shutdown in an orderly manner.

I'm not sure of the details of CouchDB, but BEAM response to SIGTERM in a
reasonable way and terminates gracefully.

--DS

2009/5/21 Eric Hanchrow <eric.hanchrow at gmail.com>

> I've got a system that manages child processes, and stops those
> processes by simply sending them a fatal signal -- in Unix parlance,
> it does "kill -9 <process ID>".  The process that it currently manages
> deal gracefully with being killed, but I'm hoping to add rabbitmq to
> this system, and would prefer not to have to write any special code
> for it -- that is, I'd like to be able to stop it, too, by sending it
> a fatal signal.  Is this a reasonable thing to do?  In particular, can
> I expect that whatever it's written to disk will remain consistent?
>
> As it happens, I am not using, and don't plan to use, any persistent
> queues; I assume this fact increases the chances I'll get away with
> this.
>
> Also, I've tried killing rabbitmq and restarting it, with clients
> connected, and have not observed anything alarming.  I _did_ see a log
> message or two like this
>
> =INFO REPORT==== 21-May-2009::15:24:28 ===
> Repaired persister log - 1 recovered, 0 bad
>
> ... but I figure those are _good_ signs, not bad.
>
> So: dumb idea, or perfectly fine?
>
> Thanks.
>
> _______________________________________________
> rabbitmq-discuss mailing list
> rabbitmq-discuss at lists.rabbitmq.com
> http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20090525/2722e916/attachment.htm 