[rabbitmq-discuss] Cleaning up after a rabbitmq-server install

Matt Pietrek mpietrek at skytap.com
Mon Apr 23 21:41:42 BST 2012

Hey Matthew,

Sorry for the delayed response - Was out of town for two weeks and
just got backed.

I understand rabbit's default choice to leave the service running
after installing - It makes the "new user" scenario much less error
prone. However, in production environments where state is very
explicitly controlled, it's considered bad form (at least around here)
to combine "installed" and "running" into a single state. We have very
explicit states, e.g.

- Install/configure services for execution - After this completes,
nothing should "just happen" to be running
- Launch services

Regarding your last point, making the user configurable via debconf,
that sounds like exactly like what we need. Please add it to whatever
request list you have!



On Mon, Apr 9, 2012 at 6:02 AM, Matthew Sackman <matthew at rabbitmq.com> wrote:
> Hi Matt,
> On Fri, Apr 06, 2012 at 09:51:04AM -0700, Matt Pietrek wrote:
>> Now, for a run-of-the-mill installation of some service ("apt-get
>> install <program-name>" ), I wouldn't expect anything to be left
>> running after the install completes. That is, installing a program
>> shouldn't just automatically leave the program running after
>> installing it, as well as other running bits and pieces.
> Hmm. My recollection is that installing things like apache, nginx,
> postgresql etc etc (i.e. system daemons) does exactly that and leaves
> them running. Please correct me if I'm wrong there, but I don't think we
> do anything abnormal.
>> However, I don't see a way to tell the rabbitmq-server install to just
>> drop the bits, and not leave anything running.
> Oh, there's probably some bizarre dpkg incantation that can do that -
> probably just "don't run the postinstall" or something, but that might
> leave the package in a badly configured state. Again, do other system
> daemons provide this sort of option? If so, how? We'll be more than
> happy to cope whatever is the standard way of achieving this for Debian.
>> The issue is: We don't want these leftover processes running as the
>> rabbitmq user hanging around after puppet completes. I've experimented
>> with adding "epmd -kill" to the Puppet scripts, and it successfully
>> kills epmd on about 30% of the nodes, but it fails (exit code != 0) on
>> the other 70%.
> Hmm, that suggests that we should probably have the user configurable
> via debconf, and then you can probably pre-seed the answers there. What
> do you reckon?
> Matthew
> _______________________________________________
> rabbitmq-discuss mailing list
> rabbitmq-discuss at lists.rabbitmq.com
> https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss

More information about the rabbitmq-discuss mailing list