Comment 79 for bug 1874075

Performing verification for rabbitmq-server in -proposed for xenial.

I installed 3.5.7-1ubuntu0.16.04.4 from -proposed, and followed the instructions I wrote in comment #59.

I sent a message to host 1, checked that host 1 was master, and host 2 was the slave. I shut host 1 down, and then sent a message to host 2. Host 2 became the new master. I shut host 2 down. I then started host 1 up again.

The rabbit service came up in a "activating" state, due to ExecStartPost=/usr/lib/rabbitmq/bin/rabbitmq-server-wait kicking in. The rabbitmq in xenial does not offer verbose logging in its /var/log/rabbitmq/rabbit.log file about waiting for host 2, so instead I focused on the systemd service. The service will time out after 60 seconds, something I noted and explained previously, which myself and @ddstreet find to be an acceptable timeout. When the timeout occurs, /usr/lib/rabbitmq/bin/rabbitmq-server-wait exits with an error code, which causes systemd to restart the service, as expected. After a 10 second wait, the service starts in the activating state, waiting for host 2 to come up. I left the service for 15 minutes, and it timed out and restarted successfully 15 times.

I then started host 2 up, and host 1 rejoined the cluster. Both hosts have the rabbit service in the active state.

The package is behaving as expected on xenial, and I am happy to mark this as verified.