--- Comment #5 from Peter Lemenkov <lemenkov(a)gmail.com> ---
(In reply to John Eckersberg from comment #4)
One other note on the standalone epmd. I used the templated socket
to the rabbitmq-server unit file, which works perfectly :)
I think we should finally add this to the service-file. John, are you aware of
any issues with this additional Reqires so far?
My only concern is that if the administrator stops rabbitmq-server.service then
epmd(a)0.0.0.0.socket still remains active. So this socket (tcp:0.0.0.0:4369)
will remain opened.
I suspect we could spice it up with some systemd magic (StopWhenUnneeded +
BindsTo + RefuseManualStart) but so far I cant figure out how to do it
properly. See my question in devel@ list:
I suppose this issue is described here:
Citing my own private email:
Although this might be related to pre-systemd version of RabbitMQ it
raises a valid question. It seems that people don't like the idea of
epmd remaining online after the RabbitMQ shutdown. Frankly speaking it
isn't a bug - what to do with another systemd-service started as a
dependency is up to systemd administrator. However I believe this
should be adjusted by adding some combination of StopWhenUnneeded +
BindsTo + RefuseManualStart to epmd@.socket / epmd@.service. I've
tried quickly but failed to implement a required functionality.
So far I have the following considerations:
* epmd@.service must refuse manual activation. It can be activated
only by the corresponding socket unit. So maybe we have to add
RefuseManualStart to the service. Quite the contrary the socket unit
counterpart can be manually activated.
* Every Erlang service (RabbitMQ) must require socket-file. Something
like Requires=epmd(a)0.0.0.0.socket. Otherwise they will try to start
their own epmd instance.
* epmd@.service and epmd@.socket must be deactivated right after the
dependent services stopped.
As I said earlier I failed to glue all of these together and would
love to hear any comments / suggestions and maybe receive a bit of
systemd-related help :)
You are receiving this mail because:
You are on the CC list for the bug.