I have a ruby app where we have several services all built off a single Docker image - my convox.yml
has under each non-default service, such as a background worker, an entry like:
build: .
command: bundle exec resque-pool
When it gets terminated (eg during a deploy), it does not seem to be gracefully shutting down (ECS/docker should be sending a SIGTERM), here’s the process tree:
PID TTY STAT TIME COMMAND
1 ? Ss 0:06 /dev/init -- /convox-env sh -c bundle exec resque-pool
6 ? S 0:00 sh -c bundle exec resque-pool
12 ? Sl 0:53 \_ resque-pool-master[app]: managing [14]
14 ? Sl 2:34 \_ resque-1.25.2: Waiting for *
If a convox service does not have a command in convox.yml
, as in something that uses the default CMD
from the Dockerfile
, it will set that process as PID 1, allowing it to get the signal as expected and gracefully shutdown. I’ve also tried using the docker init process, but that didn’t change how the command was run.
Any tricks for being able to trap & handle the signal or otherwise be able for these to gracefully terminate? I suppose I could make a separate Dockerfile
for each service, but that would be a bit of duplication.