Init scripts: hard-coded RABBITMQ_PID_FILE can be changed later in rabbitmq-env.conf

[dumbbell]

If the value of RABBITMQ_PID_FILE is changed in /etc/rabbitmq/rabbitmq-env.conf to something different than the value hard-coded in the init script, the init script says the service failed to start even if it started properly. This is because it looks for the PID file in the wrong place.

Likewise, stopping the service returns an error but the service is correctly stopped.

[michaelklishin]

Looks like 25c8e77 also addresses this one?

[dumbbell]

No, it needs a check in rabbitmq-env.

However, I have an issue on RHEL 6.5 I'm debugging.

[dumbbell]

To expand a bit beyond "No" (sorry for the short answer...), the commit you mention only fixes the argument to start-stop-daemon on Debian-like distributions. Red Hat-like distributions are not affected by this change. start-stop-daemon uses this PID file to know if the service is already running for instance. In our case, the bug was not a problem because rabbitmqctl status is executed before reaching this point to achieve the same check.

The problem here is that the init script sets RABBITMQ_PID_FILE in the environment when starting (directly or indirectly) rabbitmq-server. But rabbitmq-env.conf may override this value. When this is the case, rabbitmq-server creates the PID file at the location specified in rabbitmq-env.conf, not at the one expected by the init script. Therefore, rabbitmqctl wait (started by the init script) waits forever a PID file which will never be created.

The user can only ^C the init script. Depending on the init system, this may just interrupt the init script and leave RabbitMQ alone, or this may kill RabbitMQ.