Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Customize rabbitmq-server systemctl unit file #71

Closed
YanChii opened this issue Sep 5, 2017 · 2 comments
Closed

Customize rabbitmq-server systemctl unit file #71

YanChii opened this issue Sep 5, 2017 · 2 comments
Assignees
Milestone

Comments

@YanChii
Copy link
Contributor

YanChii commented Sep 5, 2017

We need to make sure the MQ server is running even there was some external failure (e.g. OOM kill or very slow CPU resulting in start timeouts). This can prevent unexpected "failures" of the management.
It can be achieved by
cp /usr/lib/systemd/system/rabbitmq-server.service /etc/systemd/system/rabbitmq-server.service
and adding
Restart=on-failure to [Service] section.

@dn0 dn0 assigned mbag Sep 6, 2017
@dn0 dn0 added this to the 2.6.4 milestone Sep 6, 2017
@mbag
Copy link
Contributor

mbag commented Sep 8, 2017

From man systemd.service:

When the death of the process is a result of systemd operation (e.g. service stop or restart), the service will not be restarted.

For the on-failure the info is following:

In this context, a clean exit means an exit code of 0, or one of the signals SIGHUP, SIGINT, SIGTERM or SIGPIPE, and additionally, exit statuses and signals specified in SuccessExitStatus=. If set to on-failure, the service will be restarted when the process exits with a non-zero exit code, is terminated by a signal (including on core dump, but excluding the aforementioned four signals), when an operation (such as service reload) times out, and when the configured watchdog timeout is triggered.

When set to always the service behaves like this:

If set to always, the service will be restarted regardless of whether it exited cleanly or not, got terminated abnormally by a signal, or hit a timeout.

If we choose always in case there is something really wrong with the service, it's hard to predict what will forever restarting do to the system. I think that on-failure is good choice.

@mbag mbag closed this as completed Sep 8, 2017
@mbag mbag reopened this Sep 8, 2017
@dn0
Copy link
Member

dn0 commented Sep 8, 2017

@mbag OK lets go with on-failure

mbag added a commit to erigones/esdc-ce that referenced this issue Sep 11, 2017
rabbitmq-server will be restarted automatically if it fails
This is related to issue erigones/esdc-factory#71
YanChii pushed a commit to erigones/esdc-ce that referenced this issue Sep 11, 2017
rabbitmq-server will be restarted automatically if it fails
This is related to issue erigones/esdc-factory#71
@dn0 dn0 closed this as completed Sep 11, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Development

No branches or pull requests

3 participants