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

[Eric Hanchrow]

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.