2

I am running redis-server in a Docker container on Ubuntu 14.10 x64. If I access the redis database via phpRedisAdmin, do a few edits and then get them to be saved to disk, shutdown the container and then restart it everything is fine - the edited redis keys are present and correct. However, if I edit keys and then shut down the container then restart it the edits do not stick.

Clearly, the dump.rdb file is not being saved automatically when the container is shutdown. I imagine that I could fix this by putting in an /etc/init.d script that is symlinked from /etc/rc6.d. However, I am wondering - why does shutting down a redis container not perform an orderly shutdown of the running process(es) in the container? After all, when I reboot my server (both the server & the container run Ubuntu 14.10) I do not have to explicitly commit the redis db changes to disk.

DroidOS
  • 8,530
  • 16
  • 99
  • 171
  • How are you stopping the container? – Adrian Mouat Apr 06 '15 at 09:32
  • By issuing a `docker stop -t 0 containerid`. One of the things I have discovered since posting this question that in a Docker container the usual rullevel processing does not occur. – DroidOS Apr 06 '15 at 09:39
  • 1
    If you do `-t 0` you are saying give it 0 secs before issuing a sigkill, which won't give it time to tidy up after itself. Instead remove that argument or increase to `-t 30` or something. Also, is redis pid 1 - are signals being properly proxied to it? – Adrian Mouat Apr 06 '15 at 09:55
  • Thanks, I'll try that. However - perhaps you know: if Docker containers do not run the usual runlevel script links in /etc/rc6.d what good will the -t 30 (or whatever) do since no shutdown scripts are run anyway? – DroidOS Apr 06 '15 at 09:58
  • 1
    You need to learn about unix signals. There is normally 1 process in a docker container, which will receive a SIGTERM when you run docker stop, and will shut itself down. If it doesn't shut down, docker will kill it with SIGKILL. If there are multiple processes in the container, it is up to the parent process to shutdown the child processes. – Adrian Mouat Apr 06 '15 at 10:02
  • Thanks. Wrap that up in an answer and I will upvote + accept it. – DroidOS Apr 06 '15 at 10:11

1 Answers1

3

The main process in a Docker container will be sent a SIGTERM signal when you run docker stop -t N CONTAINER. The process should then begin to shut itself down cleanly. If after N seconds (10 by default) this still hasn't happened, Docker will use a SIGKILL signal, which will kill the process without giving it a chance to clean up. The reason you were having problems was probably because you simply weren't giving Redis long enough to shutdown cleanly.

It's important to note that only the main process in the container (PID 1) will be sent signals. This means that the main process must be responsible for shutting down any child processes in the container, or you can end up with zombie processes.

If you still have problems with redis not doing what you want on shutdown, you could wrap it in a script which acts as PID 1, catches the SIGTERM signal and does whatever tidying up you want (just make sure you do shutdown redis and any other processes you've started).

Adrian Mouat
  • 44,585
  • 16
  • 110
  • 102