Waiting for Mnesia tables timeout during RabbitMQ cluster node startup

Direct Answer

The Waiting for Mnesia tables timeout ERROR line is written to the RabbitMQ startup log before the 30-second default mnesia_table_loading_timeout expires. Whether that line survives for post-mortem analysis depends entirely on how your deployment handles log files and rotation. Package installs write to /var/log/rabbitmq with built-in rotation; the official Docker image writes to stdout/stderr by default (no file rotation unless you mount a volume and enable log.file=true); Kubernetes deployments via the Cluster Operator typically rely on the container runtime's json-file driver rather than RabbitMQ's own rotation.

Log Directory and Rotation by Deployment Type

Deployment	Default Log Path	Rotation Mechanism	Key Defaults (RabbitMQ 3.10+)
Package (deb/rpm)	/var/log/rabbitmq	Built-in (log.file.rotation.*)	date/$D0, size/10485760 (10 MB), count/5 (pre-3.10) or count/10 (3.10+)
Docker (official image)	stdout/stderr (console)	Container runtime json-file driver	No file rotation unless log.file=true + volume mount at /var/log/rabbitmq
Kubernetes (Cluster Operator)	Mounted volume (emptyDir/PVC) at /var/log/rabbitmq	Container runtime json-file driver; built-in only if log.file=true	Operator's values.yaml sets date/$D0 and size/10485760 but requires log.file=true

Settings That Guarantee ERROR Line Retention

Add the following to rabbitmq.conf to keep startup ERROR lines across multiple rapid restarts:

log.file = true
log.file.rotation.date = $D0
log.file.rotation.size = 10485760
log.file.rotation.count = 10

This retains up to 10 dated/sized files (≈100 MB total), covering several restart cycles. The pre-3.10 default of count=5 is too low—repeated crash-loops will overwrite the critical ERROR line.

Built-in Rotation vs. External Shippers

• Built-in is sufficient for single-node or small clusters with low log volume and local disk durability.
• External shippers (Fluent Bit, Vector, Filebeat) are recommended for multi-node K8s clusters where you need centralized correlation across pods, durability beyond pod lifecycle, and handling of multiline Erlang stack traces.
• If using Docker/K8s console logging (RABBITMQ_LOGS=-), verify the container runtime's json-file driver is configured with max-file and max-size large enough to survive pod restarts.

Critical Additional Artifact: Crash Dumps

When the node dies before broker logs flush, erl_crash.dump may be the only artifact. It is written to the node's working directory:

• Package: /var/lib/rabbitmq/mnesia/<node>/
• Docker/K8s: container working directory (often /var/lib/rabbitmq/mnesia/<node>/ inside the container)

Crash dumps are not rotated by log.file.* settings and can grow to gigabytes. Mount a dedicated volume or monitor disk space.

Verification Steps

1. Check effective log config on a running node:

   rabbitmq-diagnostics -q log_location
   rabbitmq-diagnostics -q show_config | grep -A5 'log.file'

2. Inspect actual log files after a forced restart:

   ls -lh /var/log/rabbitmq/   # or your mounted path

   Confirm filenames match the date/size pattern.
3. Validate crash dump location:

   rabbitmq-diagnostics -q crash_dump_location

4. Review container runtime log driver settings:

   docker info | grep -A5 'Logging Driver'
   # or on K8s nodes:
   ps aux | grep kubelet | grep -E 'container-log-max-files|container-log-max-size'

One Missing Diagnostic Detail

What is your exact RabbitMQ version and deployment method (package, Docker image tag, or Cluster Operator version)? The default log.file.rotation.count changed at 3.10, and the Operator's values.yaml defaults vary by release. This changes whether the out-of-the-box config already retains enough files or if you must explicitly set count=10.