[rabbitmq-discuss] Is it reasonable to stop a rabbitmq server by sending it a fatal signal?
dave.smith.to at gmail.com
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.
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
> 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?
> rabbitmq-discuss mailing list
> rabbitmq-discuss at lists.rabbitmq.com
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the rabbitmq-discuss