Interactive docker container stop-CodePudding

I am using docker container stop to stop a container. It sends a SIGTERM signal to the child processes and the child processes might take some time to finish before exiting.

So, my docker container stop is waiting for the child processes to finish. But I have no way of knowing why it is waiting for. Is there a way of running docker container stop in an "interactive" mode or some other docker-solution, which will tell me what is the main process waiting for to exit?

Additional information: Using Hangfire to kick off these jobs and monitor these jobs.

Docker container stop documentation doesn't list any way of doing it.

One potential solution I thought of?: I have a way to know the process id of the main application which is running inside the docker. Can we somehow pipe that information to a file, which I can read simultaneously while the docker stop is working.

CodePudding user response：

you cannot follow logs and stop the container with same command. You can follow the logs in other terminal tab while closing the container in another tab.Thus it will show you the details log of that container.Here is an example:

Here i have two window of terminal in one i am stopping the container with command

docker stop f76

in another one i am following the log with

docker logs --follow f76

While stopping the container the logs printing these lines:

1:signal-handler (1671521182) Received SIGTERM scheduling shutdown...
1:M 20 Dec 2022 07:26:22.689 # User requested shutdown...
1:M 20 Dec 2022 07:26:22.689 * Saving the final RDB snapshot before exiting.
1:M 20 Dec 2022 07:26:22.704 * DB saved on disk
1:M 20 Dec 2022 07:26:22.704 # Redis is now ready to exit, bye bye...

Thus, i can know what happening in my container or what it is waiting for while stopping.

CodePudding user response：

docker stop only manages the process with pid 1 inside the container and nothing else; there's nothing more that Docker could display while it's waiting.

A Docker container normally only runs a single process. In this case the mechanics are clear: Docker sends SIGTERM to this process, waits for it to exit, and eventually sends SIGKILL.

If you do somehow have your container to set up to run multiple processes, there will be one process at the root of the process tree with process ID 1. Depending on your setup this could be supervisord, a shell, or something else. docker stop only sends SIGTERM to this single root process, and after its timeout, if this single root process hasn't exited yet, it will forcibly terminate that one process with SIGKILL. The cleanup sequence will also terminate any child processes there may happen to be, I believe immediately and less politely.

As such, there's not much that could be written from an "interactive docker stop". It sends SIGTERM immediately, and if it doesn't come back immediately, it means the process has handled the signal and not exited yet. Docker itself isn't doing any more than waiting at this point in a way that could be monitored.