[rabbitmq-discuss] rabbitmq-server restart also restarts epmd

[Garrett Smith]

I wanted to post here before digging into this, but the Debian control
scripts for rabbitmq appear to affecting a restart of epmd:

# pgrep epmd
28133
# /etc/init.d/rabbitmq-server restart
Restarting rabbitmq-server: SUCCESS
rabbitmq-server.
# pgrep epmd
29027

Needless to say, this makes other registered Erlang nodes running on
the server very cranky :)

Is this by design? Is there a preferred way to restart rabbitmq on Debian?

Thanks,
Garrett

[Matthias Radestock]

Garrett,

Post by Garrett Smith
# pgrep epmd
28133
# /etc/init.d/rabbitmq-server restart
Restarting rabbitmq-server: SUCCESS
rabbitmq-server.
# pgrep epmd
29027
Needless to say, this makes other registered Erlang nodes running on
the server very cranky :)
Is this by design? Is there a preferred way to restart rabbitmq on Debian?

This was introduced in order to prevent failures during package purge
(which attempts to remove the 'rabbitmq' user, and failed when epmd was
started by that user and is still running).

Note that it will only kill a 'rabbitmq' owned epmd, so one way to keep
epmd running is to start it explicitly, as a different user.

We could do a few other things, e.g.

- only kill epmd if it was started by the init script

- only kill epmd on package purge

- start epmd as a different user, e.g. root

They all have drawbacks too though. Any other suggestions?


Matthias.

[Matthias Radestock]

Garrett,

The approach that seems to have the fewest surprises is to kill epmd
only during a package purge. What drawback do you see there?

- this would still disturb other Erlang apps, just less frequently

- it makes start/stop asymmetric; if epmd gets started as a side-effect
of starting rabbitmq, then it should get stopped as a side effect of
stopping rabbitmq


Matthias.

[Garrett Smith]

Post by Matthias Radestock
Garrett,

The approach that seems to have the fewest surprises is to kill epmd
only during a package purge. What drawback do you see there?

- this would still disturb other Erlang apps, just less frequently
- it makes start/stop asymmetric; if epmd gets started as a side-effect of
starting rabbitmq, then it should get stopped as a side effect of stopping
rabbitmq

This problem pops up from Erlang's implicit creation of a long running
process that's relied upon multiple Erlang nodes :(

Rather than try to solve the dependency/ordering issue that's at the
heart of this, I'd punt and just take the most defensible course:

- Running the rabbitmq Erlang process is going to implicitly start
epmd under the rabbit user. This is least surprising -- it's the way
any Erlang process behaves.

- Removing the rabbitmq-server package necessitates removal of the
rabbit user, which necessitates stopping all of its processes. This is
also pretty obvious.

If a sysadmin needs to manage the shared epmd process, he/she can do
so outside the scope of rabbit. This is going to be a problem with any
Erlang application that runs under a non-privileged user.

I agree that it's never ideal to kill epmd, but short of trying to
solve Erlang's problem for them, I'd settle for this.

Garrett

[Elliot Murphy]

Post by Garrett Smith
- Removing the rabbitmq-server package necessitates removal of the
rabbit user, which necessitates stopping all of its processes. This is
also pretty obvious.

CouchDB has faced similar issues.

My understanding of Debian and Ubuntu policy/best practice is that
packages should not remove system users that they have created.

I didn't find where this is specified in debian policy, but here is a
wiki page that describes some of the problems with removing system
users: http://wiki.debian.org/AccountHandlingInMaintainerScripts

What we have done for CouchDB in Ubuntu (at the insistence/encouragement
of the core Ubuntu developers) is simply changed the package to not
remove the CouchDB user, and I'd recommend the same change for RabbitMQ.
--
Elliot Murphy | https://launchpad.net/~statik/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: OpenPGP digital signature
Url : http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20091102/e36b33dd/attachment.pgp

[David Wragg]

Hi Elliot,

Post by Elliot Murphy

Post by Garrett Smith
- Removing the rabbitmq-server package necessitates removal of the
rabbit user, which necessitates stopping all of its processes. This is
also pretty obvious.

CouchDB has faced similar issues.
My understanding of Debian and Ubuntu policy/best practice is that
packages should not remove system users that they have created.
I didn't find where this is specified in debian policy, but here is a
wiki page that describes some of the problems with removing system
users: http://wiki.debian.org/AccountHandlingInMaintainerScripts

Thanks for the link. That page contains an interesting collection of
both pros and cons of removing accounts, though it doesn't seem to
reach a definitive conclusion on the matter.

Post by Elliot Murphy
What we have done for CouchDB in Ubuntu (at the insistence/encouragement
of the core Ubuntu developers) is simply changed the package to not
remove the CouchDB user, and I'd recommend the same change for RabbitMQ.

I still tend to think that removing the rabbitmq user account when
purging is the right thing to do. Given that debian packages have
distinct 'remove' and 'purge' operations, it seems sensible to me that
'purge' should remove all traces of the package, and rabbitmq-server's
postrm script adheres to this (for example, when purging it deletes
all files that the package might have created, including log files
etc.). If the administrator wants a less thorough removal of the
package, then that is exactly what the 'remove' operation is for.
Though I accept that my view might be influenced by our frequent need
to test the rabbitmq-server packages, which makes having 'purge'
return a system to a pristine state rabbit-wise particularly useful.

But naturally, if the Debian community reaches a consensus that
deleting users is never the right thing, then we will make our package
conform. But it would be good to see a clear signal first, such as a
change to the debian-policy manual.

David

[David Wragg]

Hi Garrett,

Post by Garrett Smith
Rather than try to solve the dependency/ordering issue that's at the
- Running the rabbitmq Erlang process is going to implicitly start
epmd under the rabbit user. This is least surprising -- it's the way
any Erlang process behaves.
- Removing the rabbitmq-server package necessitates removal of the
rabbit user, which necessitates stopping all of its processes. This is
also pretty obvious.

I tend to agree that if we are killing epmd in order to remove the
rabbitmq user, then the right time to do it is immediately before the
deluser. While it would be nice if we could have a rabbitmq-specific
epmd process that gets started and killed along with the rabbitmq
server, erlang doesn't currently make that easy to achieve. I'll add
the issue to the rabbitmq tracking system.

David