I have updated the description Eric. Please have another look ** Description changed:
- ## DRAFT SRU TMPL ## - [Impact] + The startup timeouts were recently adjusted and synchronized between the + SysV and systemd startup files. - * An explanation of the effects of the bug on users and + https://github.com/rabbitmq/rabbitmq-server-release/pull/129 - * justification for backporting the fix to the stable release. + The new startup files should be included in this package. - * In addition, it is helpful, but not required, to include an - explanation of how the upload fixes this bug. + [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] - * detailed instructions how to reproduce the bug + In a clustered setup with two nodes, A and B. - * these should allow someone who is not familiar with the affected - package to reproduce the bug and verify that the updated package fixes - the problem. + 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] - * discussion of how regressions are most likely to manifest as a result - of this change. - - * It is assumed that any SRU candidate patch is well-tested before - upload and has a low overall risk of regression, but it's important - to make the effort to think about what ''could'' happen in the - event of a regression. - - * This both shows the SRU team that the risks have been considered, - and provides guidance to testers in regression-testing the SRU. - - [Other Info] - - * Anything else you think is useful to include - * Anticipate questions from users, SRU, +1 maintenance, security teams and the Technical Board - * and address these questions in advance - ## DRAFT SRU TMPL ## - - [Original 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 + 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. ** Changed in: rabbitmq-server (Ubuntu Eoan) Importance: Undecided => Low ** Changed in: rabbitmq-server (Ubuntu Bionic) Importance: Undecided => Low ** Changed in: rabbitmq-server (Ubuntu Xenial) Importance: Undecided => Low -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1874075 Title: rabbitmq-server startup timeouts differ between SysV and systemd To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/rabbitmq-server/+bug/1874075/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
