Question 182832 in Ubuntu Question posted in
The official Ubuntu documentation can be found here.

Ubuntu – Detached RabbitMQ docker container dies after I log out from the server

I’m trying to set up a RabbitMQ docker instance running on a VDS.

Here is my docker-compose config.

version: "3"

services:
  rabbitmq:
    image: rabbitmq:3-management
    ports:
      - '15672:15672'
      - '5672:5672'
    environment:
      - RABBITMQ_DEFAULT_USER=<some-user>
      - RABBITMQ_DEFAULT_PASS=<some-pass>
    hostname: 'rabbit-<hostname>'

I start this docker instance in detached mode with docker compose up -d

It starts, and it works well while I have at least one terminal connected to the server. It doesn’t have to be the one I started RabbitMQ from, but basically any open connection.

As soon as I close all the terminals, it shuts down within one minute. This is what I see in the logs.

2023-06-05 09:13:44.954939+00:00 [info] <0.591.0> Server startup complete; 4 plugins started.
2023-06-05 09:13:44.954939+00:00 [info] <0.591.0>  * rabbitmq_prometheus
2023-06-05 09:13:44.954939+00:00 [info] <0.591.0>  * rabbitmq_management
2023-06-05 09:13:44.954939+00:00 [info] <0.591.0>  * rabbitmq_web_dispatch
2023-06-05 09:13:44.954939+00:00 [info] <0.591.0>  * rabbitmq_management_agent
2023-06-05 09:20:06.739687+00:00 [notice] <0.61.0> SIGTERM received - shutting down
2023-06-05 09:20:06.739687+00:00 [notice] <0.61.0> 
2023-06-05 09:20:06.744979+00:00 [warning] <0.642.0> HTTP listener registry could not find context rabbitmq_prometheus_tls
2023-06-05 09:20:06.751396+00:00 [notice] <0.61.0> SIGTERM received - shutting down
2023-06-05 09:20:06.751396+00:00 [notice] <0.61.0> 
2023-06-05 09:20:06.752950+00:00 [warning] <0.642.0> HTTP listener registry could not find context rabbitmq_management_tls
2023-06-05 09:20:06.766258+00:00 [info] <0.230.0> Peer discovery backend rabbit_peer_discovery_classic_config does not support registration, skipping unregistration.
2023-06-05 09:20:06.766573+00:00 [info] <0.736.0> stopped TCP listener on [::]:5672
2023-06-05 09:20:06.767926+00:00 [info] <0.1569.0> Closing all connections in vhost '/' on node 'rabbit@rabbit-feedgerald' because the vhost is stopping
2023-06-05 09:20:06.768153+00:00 [info] <0.553.0> Stopping message store for directory '/var/lib/rabbitmq/mnesia/rabbit@rabbit-feedgerald/msg_stores/vhosts/628WB79CIFDYO9LJI6DKMI09L/msg_store_persistent'
2023-06-05 09:20:06.771638+00:00 [info] <0.553.0> Message store for directory '/var/lib/rabbitmq/mnesia/rabbit@rabbit-feedgerald/msg_stores/vhosts/628WB79CIFDYO9LJI6DKMI09L/msg_store_persistent' is stopped
2023-06-05 09:20:06.772045+00:00 [info] <0.549.0> Stopping message store for directory '/var/lib/rabbitmq/mnesia/rabbit@rabbit-feedgerald/msg_stores/vhosts/628WB79CIFDYO9LJI6DKMI09L/msg_store_transient'
2023-06-05 09:20:06.775578+00:00 [info] <0.549.0> Message store for directory '/var/lib/rabbitmq/mnesia/rabbit@rabbit-feedgerald/msg_stores/vhosts/628WB79CIFDYO9LJI6DKMI09L/msg_store_transient' is stopped
2023-06-05 09:20:06.777133+00:00 [info] <0.485.0> Management plugin: to stop collect_statistics.

It looks as if it had received a SIGTERM from some process. I have no idea what causes this.

This doesn’t happen to other images that I tried to run.

If there are any other logs I could provide, that could help figure out what’s going on, please tell.

Tags:

2

Answers


  1. Chosen as BEST ANSWER
    0

    It seems like adding restart: always to the docker-compose file helped. And not in the way that it restarts the container when it crashes, it has actually stopped the container from receiving the SIGTERM at all. This is weird but it works.


  2. 0

    Based on the logs you provided, it seems that RabbitMQ is receiving a SIGTERM signal, which is the standard termination signal in Unix-like systems. This signal is usually sent by the system when a process is being shut down.

    The fact that RabbitMQ shuts down when all terminals are closed suggests that it might be running as a child process of your shell session. When the shell session is terminated, it sends a SIGTERM signal to all its child processes, including RabbitMQ.

    To prevent RabbitMQ from shutting down when the shell session is closed, you can try running it as a background process using the nohup command. Here’s an example of how you can modify your docker-compose configuration:

    version: "3"

    services:
    rabbitmq:
    image: rabbitmq:3-management
    ports:
    – ‘15672:15672’
    – ‘5672:5672’
    environment:
    – RABBITMQ_DEFAULT_USER=
    – RABBITMQ_DEFAULT_PASS=
    command: nohup rabbitmq-server
    restart: always
    hostname: ‘rabbit-‘

    By using the nohup command, RabbitMQ will be detached from the terminal session and should continue running even after you close all terminals.

    Additionally, I noticed that you have the restart: always option in your docker-compose file. This ensures that the RabbitMQ container is automatically restarted if it fails or stops for any reason. It can be useful to keep RabbitMQ running consistently.

    After modifying the docker-compose file, you can bring up the RabbitMQ container again using docker-compose up -d, and it should stay running even when you close all terminals.

    Login or Signup to reply.
Please signup or login to give your own answer.

Back To Top
Search