[bitnami/rabbitmq] Readiness failed when memoryHighWatermark enabled

[ohrab-hacken]

Name and Version

bitnami/rabbitmq 12.6.1

What architecture are you using?

amd64

What steps will reproduce the bug?

Deploy chart with following value:

memoryHighWatermark:
  enabled: true

Are you using any custom parameters or values?

resources:
  limits:
    memory: 256Mi
  requests:
    cpu: 10m
    memory: 256Mi

persistence:
  enabled: true
  size: 8Gi

auth:
  ## @param auth.username RabbitMQ application username
  ## ref: https://github.com/bitnami/containers/tree/main/bitnami/rabbitmq#environment-variables
  ##
  username: rabbitmq

tcpListenOptions:
  keepalive: false
  linger:
    lingerOn: true
    timeout: 0

memoryHighWatermark:
  enabled: true

What is the expected behavior?

RabbitMQ up and running

What do you see instead?

RabbitMQ does not start cause readiness probe failed:

  Warning  Unhealthy  13s   kubelet            Readiness probe failed:   % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
\r  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0\r  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0
curl: (22) The requested URL returned error: 503 Service Unavailable

Logs looks good:

2023-12-28 15:04:19.303222+00:00 [info] <0.617.0> Server startup complete; 7 plugins started.
2023-12-28 15:04:19.303222+00:00 [info] <0.617.0>  * rabbitmq_prometheus
2023-12-28 15:04:19.303222+00:00 [info] <0.617.0>  * rabbitmq_auth_backend_ldap
2023-12-28 15:04:19.303222+00:00 [info] <0.617.0>  * rabbitmq_peer_discovery_k8s
2023-12-28 15:04:19.303222+00:00 [info] <0.617.0>  * rabbitmq_peer_discovery_common
2023-12-28 15:04:19.303222+00:00 [info] <0.617.0>  * rabbitmq_management
2023-12-28 15:04:19.303222+00:00 [info] <0.617.0>  * rabbitmq_management_agent
2023-12-28 15:04:19.303222+00:00 [info] <0.617.0>  * rabbitmq_web_dispatch
2023-12-28 15:04:19.494222+00:00 [info] <0.9.0> Time to start RabbitMQ: 10013767 us

Additional information

rabbitmq-config

No namespace set, using default: rabbitmq
rabbitmq.conf: ## Username and password
##
default_user = rabbitmq
## Clustering
##
cluster_name = rabbitmq
cluster_formation.peer_discovery_backend  = rabbit_peer_discovery_k8s
cluster_formation.k8s.host = kubernetes.default
cluster_formation.k8s.address_type = hostname
cluster_formation.k8s.service_name = rabbitmq-headless
cluster_formation.k8s.hostname_suffix = .rabbitmq-headless.rabbitmq.svc.cluster.local
cluster_formation.node_cleanup.interval = 10
cluster_formation.node_cleanup.only_log_warning = true
cluster_partition_handling = autoheal

# queue master locator
queue_master_locator = min-masters
# enable loopback user
loopback_users.rabbitmq = false
#default_vhost = rabbitmq-vhost
#disk_free_limit.absolute = 50MB
## Memory Threshold
##
total_memory_available_override_value = 268435456
vm_memory_high_watermark.relative = 0.4
## TCP Listen Options
##
tcp_listen_options.backlog = 128
tcp_listen_options.nodelay = true
tcp_listen_options.linger.on      = true
tcp_listen_options.linger.timeout = 0
tcp_listen_options.keepalive = false

[jotamartos]

Hi @ohrab-hacken,

This issue is not related to the memoryHighWatermark parameter, it's about the memory limits you are setting in the values.yaml file. For example, you get the same error when installing the chart using this command

helm install rabbitmq bitnami/rabbitmq --set resources.limits.memory="256Mi"

If you set a higher memory limit, you won't run into issues

helm install rabbitmq bitnami/rabbitmq --set memoryHighWatermark.enabled=true --set memoryHighWatermark.type="relative" --set memoryHighWatermark.value="0.4" --set resources.limits.memory="1Gi"

[github-actions]

This Issue has been automatically marked as "stale" because it has not had recent activity (for 15 days). It will be closed if no further activity occurs. Thanks for the feedback.

[github-actions]

Due to the lack of activity in the last 5 days since it was marked as "stale", we proceed to close this Issue. Do not hesitate to reopen it later if necessary.