Reasons for Zombies 💀 💀 💀 Docker Container not shutting down when running Procodile? about procodile HOT 8 CLOSED

For reference, here's the relevant code which demonstrates what signals actually do...

@signal_handler.register('TERM') { stop_supervisor }
@signal_handler.register('INT') { stop(:stop_supervisor => true) }
@signal_handler.register('USR1') { restart }
@signal_handler.register('HUP') { reload_config }

from procodile.

For debugging, take a look at the procodile.log which should show everything the supervisor is doing.

from procodile.

If you send a KILL signal to procodile, it will just kill the supervisor immediately. You should be sending INT to the procodile if you want it to shut down cleanly and stop its child processes too.

Edited to change TERM to INT. If you send the TERM signal it only stops the supervisor. If you send INT it stops everything.

from procodile.

Thanks @adamcooke, I'm talking about the following scenario:

1. I setup a Docker Container & run a bash session, ie:
   docker exec -it xx_container_name_xx bash
   which just starts an interactive bash terminal session.

2. Then run Procodile - procodile start (without --dev/foreground mode, runs as daemon?), and can confirm the supervisor starts up with a PID and confirmed by ps aux.

3. Then go to kill the bash session, by Ctrl+C (TERM), and it just sits there, doing nothing, doesn't disconnect from the bash session.

What is Interesting: - if I run a seperate bash session into the same Docker container, it will connect, and disconnect without any problems, whilst the other one still sits there?

Questions:

• Could it be one of the processes/workers holding it up?
• How can I debug what is happening behind the scenes on the exit/TERM sig?
• My understanding is that Ctrl+C sends the TERM signal?

from procodile.

If you send a TERM to bash, this will be propagated to its child processes (in this case the procodile supervisor). The supervisor will receive this and stop itself (but not its child processes). The processes that the supervisor started are started in a new process group so they won't receive any signals from upstream which means they'll likely continue indefinitely without any supervision.

Docker is possible just be waiting for all processes within the container to stop before actually stopping itself.

from procodile.

To answer your last question, CTRL+C usually sends the INT signal.

from procodile.

Great thanks @adamcooke, so I've determined that if Procodile is running in the foreground (ie, I can see the log trails, using --dev) then if I issue the Ctrl+C command, it will shut down, but not if it's running in normal mode procodile start without the --dev flag?

from procodile.

A bit more investigation on this, it seems that running the way that the Docker container is initiated defines whether or not Procodile is cleanly shutdown when escaping using Ctrl+C in a bash session:

from procodile.