Using trap to perform environment cleanup before graceful shutdown of docker container

When a running container is terminated, how can we perform some predefined actions, such as cleaning up the environment before the container completely exits? This is a hook experience similar to pre stop. However, Docker itself cannot provide this capability. This article combines the Linux built-in command trap to implement custom operations before the container is gracefully closed.

When a running container is terminated, how can we perform some predefined actions, such as cleaning up the environment before the container completely exits? This is a hook experience similar to pre stop. However, Docker itself cannot provide this capability. This article combines the Linux built-in command trap to implement custom operations before the container is gracefully closed.

How to close a container

I understand there are three ways to shut down a running container, all of which are initiated by the docker command line.

• The first one is a more elegant way docker stop ContainerID
• The second one seems more arbitrary: docker rm -f ContainerID
• The third type is used by fewer people docker kill --signal=KILL ContainerID

The designers of Docker would not design three command combinations for shutting down containers for no reason. In what scenarios should the three methods be used?

These three ways of terminating containers are slightly different. Before explaining these differences, it is necessary to mention some knowledge points that seem to be unrelated to containers - SIGNAL.

Processes and Signals

Users can communicate with processes by sending signals.

Almost every operation and maintenance engineer has executed the following command to kill a process:

kill -9 PID

This command seems to be correct, I "killed" a process, but why "-9"?

9 is the code for the signal SIGKILL. The above command actually sends a signal to the corresponding process, a signal that can kill the process.

The real meaning of the kill command is to send a specified signal to the process. In addition to SIGKILL(9), it can also send a variety of other signals:

root@ubuntuserver:~# kill --help

kill: kill [-s sigspec | -n signum | -sigspec] pid | jobspec ... or kill -l [sigspec]

Send a signal to a job.

root@ubuntuserver:~# kill -l

1) SIGHUP 2) SIGINT 3) SIGQUIT 4) SIGILL 5) SIGTRAP

6) SIGABRT 7) SIGBUS 8) SIGFPE 9) SIGKILL 10) SIGUSR1

11) SIGSEGV 12) SIGUSR2 13) SIGPIPE 14) SIGALRM 15) SIGTERM

16) SIGSTKFLT 17) SIGCHLD 18) SIGCONT 19) SIGSTOP 20) SIGTSTP

21) SIGTTIN 22) SIGTTOU 23) SIGURG 24) SIGXCPU 25) SIGXFSZ

26) SIGVTALRM 27) SIGPROF 28) SIGWINCH 29) SIGIO 30) SIGPWR

31) SIGSYS 34) SIGRTMIN 35) SIGRTMIN+1 36) SIGRTMIN+2 37) SIGRTMIN+3

38) SIGRTMIN+4 39) SIGRTMIN+5 40) SIGRTMIN+6 41) SIGRTMIN+7 42) SIGRTMIN+8

43) SIGRTMIN+9 44) SIGRTMIN+10 45) SIGRTMIN+11 46) SIGRTMIN+12 47) SIGRTMIN+13

48) SIGRTMIN+14 49) SIGRTMIN+15 50) SIGRTMAX-14 51) SIGRTMAX-13 52) SIGRTMAX-12

53) SIGRTMAX-11 54) SIGRTMAX-10 55) SIGRTMAX-9 56) SIGRTMAX-8 57) SIGRTMAX-7

58) SIGRTMAX-6 59) SIGRTMAX-5 60) SIGRTMAX-4 61) SIGRTMAX-3 62) SIGRTMAX-2

63) SIGRTMAX-1 64) SIGRTMAX

I have no intention of explaining the meaning of each signal in detail. My skills are still far from that. I will only pick out the knowledge related to our topic for explanation here.

There are two signals related to our topic, SIGTERM and SIGKILL .

SIGTERM is the default signal sent by the kill command. When the user requests to terminate the process, a SIGTERM signal is generated. The SIGTERM signal can be caught or ignored. This allows the process to release held resources and save its state before terminating.

SIGKILL Sending a SIGKILL signal to a process causes it to terminate (KILL) immediately. Unlike SIGTERM, this signal cannot be caught or ignored, and the receiving process must not perform any cleanup upon receiving this signal. But sometimes kill -9 may not necessarily kill the process and release resources. There are some special cases:

• Zombie processes cannot be killed because they are already dead and are waiting for their parent process to reap them.
• Blocked processes do not die until they wake up again. The init process is special:
• init does not receive any signal that it is not intended to handle, so it ignores SIGKILL. There is an exception to this rule. If init on Linux is ptrace, it can receive SIGKILL and be killed.
• A process in an uninterruptible sleep may not terminate (and release its resources) even if it is sent SIGKILL. This is one of the few situations where a Unix system must be rebooted to resolve a temporary software problem.

Containers and Signals

The essence of a container is a group of encapsulated processes. Therefore, closing a running container through the three command line methods mentioned at the beginning is essentially a process of interacting with the process in the container by sending signals to "kill" it.

• docker stop

When you execute docker stop ContainerID , a SIGTERM signal will be sent to the main process in the container. After a grace period, SIGKILL signal will be sent to completely kill the container.

The original text of the Docker manual is as follows:

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

• docker rm -f

Executing docker rm -f ContainerID will send a SIGKILL signal directly to the main process in the container. After the container is killed, the container will also be deleted. Judging from the operation of deleting the container, this command is used to delete a stopped container, not to stop a running container.

• docker kill

Executing docker kill --signal=KILL ContainerID is a way to send various custom signals to the main process of the container. In other words, it is the kill command for containers. The current command is sending a SIGKILL signal to the container main process.

By comparison, docker rm -f ContainerID should not be used to stop a running container. Among the remaining two methods, docker stop ContainerID is obviously more elegant. It can not only ensure that the container will be eventually killed, but also provide SIGTERM for users to capture and process later.

Now let’s finally get to the point.

Capture the signal and process it

The signal SIGTERM is a signal that can be caught. When the container main process captures this signal, it can trigger the pre-designed logic to complete the scheduled tasks before completely exiting. For example, it can clean up the execution environment, save data, close other processes that are not controlled by the main process, and so on. In some scenarios, this requirement is very prominent.

Linux provides a built-in trap command that is responsible for capturing signals and ensuring that certain tasks are performed before the process exits completely.

root@ubuntuserver:~# trap --help

trap: trap [-lp] [[arg] signal_spec ...]

Trap signals and other events.

The basic usage is as follows:

trap do_some_things SIGSPEC

The idea is clear. We need to add the trap instruction to the container startup script to complete all the things that the container needs to do before exiting.

The following is an example of a script that is executed as the ENTRYPOINT of a container.

#!/bin/bash

function clean_up_term {
  rm -rf /data/tmp
  echo "clean_up_term in execution"
}

trap clean_up_term SIGTERM

for ((i=1;i<=1000;i++))
  do
    echo "Wait for $i"
    sleep 1
  done 

After the container is started, the docker stop ContainerID command is executed from another terminal and the following results can be observed.

guox@MacBook-Pro-For-Guox: /Users/guox/GitHub/test-plugin git:(master) ✗

➜ docker run -ti --name=clean -v $(pwd)/data:/data clean

Wait for 1

Wait for 2

Wait for 3

Wait for 4

Wait for 5

Wait for 6

Wait for 7

Wait for 8

Wait for 9

Wait for 10

Wait for 11

Wait for 12

Wait for 13

clean_up_term in execution

Wait for 14

Wait for 15

Wait for 16

Wait for 17

Wait for 18

Wait for 19

Wait for 20

Wait for 21

Wait for 22

Wait for 23

guox@MacBook-Pro-For-Guox: /Users/guox/GitHub/test-plugin git:(master) ✗

The SIGTERM signal is indeed caught by the container and the relevant cleanup operations are performed. docker stop ContainerID provides a grace period, so after the cleanup operation is performed, the container main process continues to execute for a while before exiting.

This is the end of this article about using trap to perform environment cleanup before the docker container is gracefully closed. For more information about docker container execution environment cleanup, please search 123WORDPRESS.COM's previous articles or continue to browse the following related articles. I hope you will support 123WORDPRESS.COM in the future!