[Bug 1874075] Re: rabbitmq-server startup timeouts differ between SysV and systemd
Eric Desrochers
eric.desrochers at canonical.com
Thu Apr 23 14:58:36 UTC 2020
The rationale behind not fixing Eoan can be found in the LP: #1773324
Note that Eoan will reach EOL in July 2020.
- Eric
--
You received this bug notification because you are a member of Ubuntu
OpenStack, which is subscribed to rabbitmq-server in Ubuntu.
https://bugs.launchpad.net/bugs/1874075
Title:
rabbitmq-server startup timeouts differ between SysV and systemd
Status in rabbitmq-server package in Ubuntu:
In Progress
Status in rabbitmq-server source package in Xenial:
In Progress
Status in rabbitmq-server source package in Bionic:
In Progress
Status in rabbitmq-server source package in Eoan:
Won't Fix
Status in rabbitmq-server source package in Focal:
In Progress
Bug description:
The startup timeouts were recently adjusted and synchronized between
the SysV and systemd startup files.
https://github.com/rabbitmq/rabbitmq-server-release/pull/129
The new startup files should be included in this package.
[Impact]
After starting the RabbitMQ server process, the startup script will
wait for the server to start by calling `rabbitmqctl wait` and will
time out after 10 s.
The startup time of the server depends on how quickly the Mnesia
database becomes available and the server will time out after
`mnesia_table_loading_retry_timeout` ms times
`mnesia_table_loading_retry_limit` retries. By default this wait is
30,000 ms times 10 retries, i.e. 300 s.
The mismatch between these two timeout values might lead to the
startup script failing prematurely while the server is still waiting
for the Mnesia tables.
This change introduces variable `RABBITMQ_STARTUP_TIMEOUT` and the
`--timeout` option into the startup script. The default value for this
timeout is set to 10 minutes (600 seconds).
This change also updates the systemd service file to match the timeout
values between the two service management methods.
[Test Case]
In a clustered setup with two nodes, A and B.
1. create queue on A
2. shut down B
3. shut down A
4. boot B
The broker on B will wait for A. The systemd service will wait for 10
seconds and then fail. Boot A and the rabbitmq-server process on B
will complete startup.
[Regression Potential]
This change alters the behavior of the startup scripts when the Mnesia
database takes long to become available. This might lead to failures
further down the service dependency chain.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/rabbitmq-server/+bug/1874075/+subscriptions
More information about the Ubuntu-openstack-bugs
mailing list