Shulou(Shulou.com)06/02 Report--

This article focuses on "how to use trap to execute the environment before the docker container is closed". Interested friends may wish to take a look. The method introduced in this paper is simple, fast and practical. Let the editor take you to learn how to use trap to execute the environment before the docker container is closed.

When a running container is terminated, how to perform some predefined actions, such as cleaning up the environment before the container exits completely. This is a hook experience similar to pre stop. However, docker itself does not provide this capability. This article combines the Linux built-in command trap to enable custom operations to be performed before the container is gracefully closed.

When a running container is terminated, how to perform some predefined operations, such as cleaning up the environment before the container exits completely. This is a hook experience similar to pre stop. However, docker itself does not provide this capability. This article combines the Linux built-in command trap to enable custom operations to be performed before the container is gracefully closed.

How to close a container

I've learned that there are three ways to close a running container, all initiated by the docker command line.

The first is the more elegant way, docker stop ContainerID.

The second seems to be more arbitrary docker rm-f ContainerID.

The third kind of user will have a lot less docker kill-signal=KILL ContainerID.

Docker designers naturally don't design a combination of three commands to close the container for no reason. in what scenarios should all three methods be used?

These three ways of terminating a container are slightly different, and before explaining these differences, you need to mention some knowledge points that seem to have nothing to do with the container-SIGNAL.

Process and signal

Users can communicate with the process by sending signals.

Basically every operation engineer has executed the following command to kill a process:

Kill-9 PID

This command seems appropriate. I "killed" a process, but why "- 9"?

9 is the code name of 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, and a variety of other signals can be sent in addition to SIGKILL (9):

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) SIGKILL10) SIGUSR1

11) SIGSEGV12) SIGUSR213) SIGPIPE14) SIGALRM15) SIGTERM

16) SIGSTKFLT17) SIGCHLD18) SIGCONT19) SIGSTOP20) SIGTSTP

21) SIGTTIN22) SIGTTOU23) SIGURG24) SIGXCPU25) SIGXFSZ

26) SIGVTALRM27) SIGPROF28) SIGWINCH29) SIGIO30) SIGPWR

31) SIGSYS34) SIGRTMIN35) SIGRTMIN+136) SIGRTMIN+237) SIGRTMIN+3

38) SIGRTMIN+439) SIGRTMIN+540) SIGRTMIN+641) SIGRTMIN+742) SIGRTMIN+8

43) SIGRTMIN+944) SIGRTMIN+1045) SIGRTMIN+1146) SIGRTMIN+1247) SIGRTMIN+13

48) SIGRTMIN+1449) SIGRTMIN+1550) SIGRTMAX-1451) SIGRTMAX-1352) SIGRTMAX-12

53) SIGRTMAX-1154) SIGRTMAX-1055) SIGRTMAX-956) SIGRTMAX-857) SIGRTMAX-7

58) SIGRTMAX-659) SIGRTMAX-560) SIGRTMAX-461) SIGRTMAX-362) SIGRTMAX-2

63) SIGRTMAX-164) SIGRTMAX

I have no intention to explain the meaning of each signal in detail. My skills are still far away. I only choose the knowledge related to our subject here to elaborate.

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

Can the signal name code be captured or ignored? SIGTERM15 can not be SIGKILL9.

SIGTERM is the default signal sent by the kill command. When the user requests to terminate the process, a SIGTERM signal is generated. SIGTERM signals can be captured or ignored. This allows the process to release occupied resources and save its state before it ends.

SIGKILL sends SIGKILL signals to a process to cause it to terminate immediately (KILL). Unlike SIGTERM, this signal cannot be captured or ignored, and the receiving process cannot perform any cleanup when it is received. But sometimes kill-9 doesn't necessarily kill processes and release resources. There are still some special circumstances:

Zombie processes cannot be killed because they are dead and are waiting for their parent process to harvest them.

Processes that are blocked do not die until they wake up again. The init process is special:

Init does not receive any signals that it does not intend to process, so it ignores SIGKILL. There is one exception to this rule. If init on Linux is ptrace, it can receive SIGKILL and be killed.

A process in uninterruptible sleep may not terminate (and release its resources) even if it sends a SIGKILL. This is one of the few situations in which the Unix system must be rebooted to resolve temporary software problems.

Containers and signals

The essence of a container is a set of encapsulated processes. So closing a running container through the three command line methods mentioned at the beginning is also a process of interacting with the process in the container by sending signals to make it "killed".

Docker stop

Executing docker stop ContainerID first sends a SIGTERM signal to the main process in the container, and after a grace period, the SIGKILL signal is sent to kill the container completely.

The original 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 sends a SIGKILL signal directly to the main process in the container and deletes the container after the container is killed. From the point of view of the delete container operation, 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 special way to send various custom signals to the container main process. In other words, it is a container-oriented kill command. 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 running containers. Between the other two ways, docker stop ContainerID is obviously more elegant, which not only ensures that the container will be eventually killed, but also provides SIGTERM for subsequent capture.

And then it's time to get down to business.

Capture and process the signal

Signal SIGTERM is a kind of signal that can be captured. When the container master process captures this signal, it can trigger the pre-designed logic to complete the scheduled task before exiting completely. For example, you can clean up the environment, save data, shut down 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 captures signals and ensures 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.

Its basic usage is as follows:

Trap do_some_things SIGSPEC

The idea is clear. We need to add the trap directive to the container's startup script to do everything the container needs to do before exiting.

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

#! / bin/bashfunction clean_up_term {rm-rf / data/tmp echo "clean_up_term in execution"} trap clean_up_term SIGTERMfor (

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.