A detailed explanation of the phenomenon of container startup and flashback in the FastDFS environment built by Docker

Today, when Xiaobian learned the practical knowledge of FastDFS, he needed to use Docker to build the FastDFS environment. During the construction of the FastDFS environment, the editor followed the standard environment construction steps normally, but during the construction process, there were The container crashed, and the error standard_init_linux.go:195: exec user process caused "exec format error" appeared in the log information of the container . This phenomenon has troubled the editor for a long time. After many attempts, the editor finally found The solution to the problem, the beginning of the story goes like this:

1. First, the editor pulled the FastDFS image from docker, and the pull was successful

 2. The editor started to create related containers, because two containers need to be created in the process, and both containers have encountered the same problem. Here, one of the containers will be displayed, and the other container is the same. The command for container creation There is no demonstration here, you can go to the Internet to view it.

You can see that the container in the red box above is the container created by the editor. After the container was created, it was not started immediately, so the editor started the container manually.

 So far everything is normal here, but when I use the docker ps command to view the currently running containers, the following situation appears: empty, and there is no container that starts normally

 3. In the above situation, the editor repeated the experiment many times, but there was no way to start the container, so I used the docker logs tracker1 command to view the log information of the container. After a closer look, the following interface appeared, showing standard_init_linux.go: 195 : exec user process caused "exec format error" , this error means that the execution of the user process caused an execution format error

It is also the first time for me to encounter this kind of situation, but I have also encountered this situation when I installed and used docker in my own linux virtual machine before. After wandering in the ocean of blog knowledge for many times, I finally found this situation. The key point of the problem is that the architecture of the image is different from the architecture of my virtual machine 

4. The solution to the problem ultimately depends on a netizen's post, which mentioned how to use the docker command to view the mirror structure, docker inspect morunchang/fastdfs , this really found the problem, you can see my FastDFS mirror The architecture is amd64

 I checked the architecture of my virtual machine system again, using the command uname -a to query, the results are as follows, you can see that the architecture of my virtual machine is aarch64

 The architecture of the virtual machine and the mirror image are different, so the above problem arises, because the computer of the editor is an M1 chip, so the installation of the virtual machine can only choose the aarch64 architecture system

5. So the editor went to the official docker website to check the images related to FastDFS, and found that the images installed by the editor did not match the architecture of my system. 

But in the end, the editor still found a FastDFS image that can be used on the aarch64 architecture.

 So re-establish the FastDFS environment, pull the image, and re-create the relevant container

Finally, the container was successfully started, and there was no flashback imagination, and the problem was solved 

 

Guess you like

Origin blog.csdn.net/weixin_50249953/article/details/128551187