[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:26:33 BST 2009
RabbitMQ I meant. Subscribed to too many mailing lists.
2009/5/25 Dave Smith <dave.smith.to at gmail.com>
> 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