Redis is shutting down for no reason in docker container

Question

I am trying to launch a redis docker container using docker-compose, but I always get this error. This is my docker-compose run commands docker-compose -f docker-compose.yml build and docker-compose -f docker-compose.yml up -d --force-recreate. I am running the docker containers on aws ecs and using a t2.micro ec2 instance. I am not sure if that is the reason why. Any insight would be helpful.

I have also included my docker-compose.yml

version: '2.1'

services:
  redis:
    image: redis:latest
    container_name: redis
    volumes: 
      - redis_data:/data
    ports: 
      - 6379:6379
  app:
    image: custom_image
    build: .
    depends_on:
      redis:
        condition: service_started
    ports:
      - 8003:8003
    links:
      - redis
volumes:
  redis_data:

Error

1:C 11 Sep 00:18:34.345 # oO0OoO0OoO0Oo Redis is starting oO0OoO0OoO0Oo
1:C 11 Sep 00:18:34.348 # Redis version=4.0.11, bits=64, commit=00000000, modified=0, pid=1, just started
1:C 11 Sep 00:18:34.348 # Warning: no config file specified, using the default config. In order to specify a config file use redis-server /path/to/redis.conf
1:M 11 Sep 00:18:34.349 # You requested maxclients of 10000 requiring at least 10032 max file descriptors.
1:M 11 Sep 00:18:34.349 # Server can't set maximum open files to 10032 because of OS error: Operation not permitted.
1:M 11 Sep 00:18:34.349 # Current maximum open files is 4096. maxclients has been reduced to 4064 to compensate for low ulimit. If you need higher maxclients increase 'ulimit -n'.
1:M 11 Sep 00:18:34.350 * Running mode=standalone, port=6379.
1:M 11 Sep 00:18:34.350 # WARNING: The TCP backlog setting of 511 cannot be enforced because /proc/sys/net/core/somaxconn is set to the lower value of 128.
1:M 11 Sep 00:18:34.350 # Server initialized
1:M 11 Sep 00:18:34.350 # WARNING overcommit_memory is set to 0! Background save may fail under low memory condition. To fix this issue add 'vm.overcommit_memory = 1' to /etc/sysctl.conf and then reboot or run the command 'sysctl vm.overcommit_memory=1' for this to take effect.
1:M 11 Sep 00:18:34.350 # WARNING you have Transparent Huge Pages (THP) support enabled in your kernel. This will create latency and memory usage issues with Redis. To fix this issue run the command 'echo never > /sys/kernel/mm/transparent_hugepage/enabled' as root, and add it to your /etc/rc.local in order to retain the setting after a reboot. Redis must be restarted after THP is disabled.
1:M 11 Sep 00:18:34.350 * Ready to accept connections
1:signal-handler (1536625117) Received SIGTERM scheduling shutdown...
1:M 11 Sep 00:18:37.375 # User requested shutdown...
1:M 11 Sep 00:18:37.375 * Saving the final RDB snapshot before exiting.
1:M 11 Sep 00:18:37.378 * DB saved on disk
1:M 11 Sep 00:18:37.378 # Redis is now ready to exit, bye bye...

Ethic

can you checkout any logs from ecs?, Also can you try with a more recent version of compose? – Hillaryhillbilly

those are the logs from ecs also I am on the latest version of compose (1.22.0) – Ethic

Running it locally would eliminate whether AWS is the problem. It's possible that your client container (custom_image) is connecting to the server and telling it to terminate. I took your docker-compose file, dropped the app service (partly because I don't have custom_image to try and the Redis server starts up without issue for me and waits Ready to accept connections. – Melodeemelodeon

it works fine on my local computer. I am 99% sure its not my custom_image. I have a feeling its the ec2 instance that is shutting it down. (github.com/antirez/redis/issues/1396). I am not to sure how this was solved. Any ideas? – Ethic

I've got this too. – Malikamalin

Were you able to figure this out? Running into the same issue – Logbook

I'm having the same issue running redis container in AWS EC2. It receive SIGTERM out of no where. check server uptime indicate the server did not restart. Redis is running without default user and password enable so only application user is able to connnect. – Nagel

Answer 1

Ran into the same issues. After a bit of digging we found that it was killed by systemd due to inactive. Run systemctl show docker.service command show that the inactive and active enter timestamp match up with when the redis service stop and start again.

InactiveEnterTimestamp=Tue 2021-08-03 22:07:19 AEST
ActiveEnterTimestamp=Wed 2021-08-04 09:30:36 AEST

Our solution is just to perform some activity on redis so that it doesn't enter inactive state.

Nagel

Systemd doesn't monitor for "activity" it thus also doesn't simply shut down something because you didn't use it. – Crape