I have a v6.10.0 Node server on my macOS that is automatically started from the CMD
in the Dockerfile
. Normally in my local development un-containerized environment I will use CTRL+C to kill the server. Not being able to (or not knowing how to) do this in the container, I resort to ps aux | grep node
to try to manually kill the processes. So, I get something like this:
myapp [master] :> kubectl exec -it web-3127363242-xb50k bash root@web-3127363242-xb50k:/usr/src/app# ps aux | grep node root 15 0.4 0.9 883000 35804 ? Sl 05:49 0:00 node /usr/src/app/node_modules/.bin/concurrent --kill-others npm run start-prod npm run start-prod-api root 43 0.1 0.6 743636 25240 ? Sl 05:49 0:00 node /usr/src/app/node_modules/.bin/better-npm-run start-prod root 44 0.1 0.6 743636 25140 ? Sl 05:49 0:00 node /usr/src/app/node_modules/.bin/better-npm-run start-prod-api root 55 0.0 0.0 4356 740 ? S 05:49 0:00 sh -c node ./bin/server.js root 56 0.0 0.0 4356 820 ? S 05:49 0:00 sh -c node ./bin/api.js root 57 18.6 4.9 1018088 189416 ? Sl 05:49 0:08 node ./bin/server.js root 58 13.9 5.2 1343296 197576 ? Sl 05:49 0:06 node ./bin/api.js root 77 0.0 0.0 11128 1024 ? S+ 05:50 0:00 grep node
When I try to kill one of them by
kill -9 15
I am taken out of my container’s shell and back to my computer’s shell. When I enter the container again, I see that the process is still there with the same process id. This example uses a Kubernetes pod but I believe I have the same result with entering a Docker container using the docker exec
command.
Advertisement
Answer
Every docker container has an ENTRYPOINT that will either be set in the dockerfile, using ENTRYPOINT
or CMD
declarations, or specified in the run command docker run myimage:tag "entrypoint_command"
. When the ENTRYPOINT process is killed, I think the container gets killed as well. The docker exec
, as I understand it, is kind of like “attaching” command to a container. But if the ENTRYPOINT is down there is no container to attach to.
Kubernetes will restart a container after failure as far as I understand it. Which might be the reason you see the process is back up. I haven’t really worked with Kubernetes but I’d try and play around with the way that the replications are scaled to terminate your process.