I have an application that uses shared memory, while running application we occupy some shared memory and when we kill the process we release those memory like we are suppose to do.

The question I am wondering is when I am running this application inside docker container and if docker itself is killed say using docker kill docker_id. I have seen that SIGINT of process is not called sometime and container just got killed and removed.

I want to understand what happens to shared memory I allocated in my application if docker itself is removed which properly closing the app.

Will this result in memory leak or docker take care of it itself and memory is released. Is there any way I can handle this if there is an actual memory leak happening.

CodePudding user response：

docker kill sends a signal to the main process running in a container, the same way as the normal Unix kill(1) command. Note, though, that docker kill normally sends SIGKILL, the same as shell kill -9; a process can't observe SIGKILL or react to it in any way, it's just immediately killed off.

So, yes, it's possible that docker kill container_id will cause a leak of system resources, in the same way that kill -9 process_id would without Docker.

It's more common to docker stop a container. When you do,

The main process inside the container will receive SIGTERM, and after a grace period, SIGKILL.

So long as you subscribe to SIGTERM and do your cleanup promptly (the default timeout is 10 seconds) this should avoid the resource leak.

You can also specify an alternate signal to docker kill but it wouldn't necessarily be my default approach here

docker kill --signal=SIGINT container_id