[Bug 1874075] Re: rabbitmq-server startup timeouts differ between SysV and systemd

[Nicolas Bock]

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
Sponsors Team, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/1874075

Title:
  rabbitmq-server startup timeouts differ between SysV and systemd

Status in rabbitmq-server package in Ubuntu:
  New
Status in rabbitmq-server source package in Xenial:
  New
Status in rabbitmq-server source package in Bionic:
  New
Status in rabbitmq-server source package in Eoan:
  New
Status in rabbitmq-server source package in Focal:
  New

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