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

[Dave Smith]

RabbitMQ I meant.  Subscribed to too many mailing lists.

--DS


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.
>
> --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/d9d7308c/attachment.htm