Als Xiaobian heute die praktischen Kenntnisse von FastDFS erlernte, musste er Docker verwenden, um die FastDFS-Umgebung zu erstellen. Während des Aufbaus der FastDFS-Umgebung befolgte der Editor normalerweise die Standardschritte zum Erstellen der Umgebung, aber während des Erstellungsprozesses gab es Der Container stürzte ab und in den Protokollinformationen des Containers wurde der Fehler „standard_init_linux.go:195: Exec-Benutzerprozess verursachte „Exec-Formatfehler““ angezeigt . Dieses Phänomen hat den Editor schon lange beunruhigt. Nach vielen Versuchen hat der Editor endlich die Lösung gefunden Zum Problem geht der Anfang der Geschichte so:
1. Zuerst hat der Editor das FastDFS-Image aus Docker abgerufen, und der Abruf war erfolgreich
2. Der Editor hat mit der Erstellung verwandter Container begonnen, da dabei zwei Container erstellt werden müssen und bei beiden Containern das gleiche Problem aufgetreten ist. Hier wird einer der Container angezeigt und der andere Container ist derselbe. Der Befehl Für die Containererstellung gibt es hier keine Demonstration. Sie können sie im Internet ansehen.
Sie können sehen, dass der Container im roten Feld oben der vom Editor erstellte Container ist. Nachdem der Container erstellt wurde, wurde er nicht sofort gestartet, sodass der Editor den Container manuell startete.
Bisher ist hier alles normal, aber wenn ich den Docker-Befehl ps verwende, um die aktuell ausgeführten Container anzuzeigen, erscheint die folgende Situation: leer, und es gibt keinen Container, der normal startet
3. In der obigen Situation wiederholte der Editor das Experiment viele Male, aber es gab keine Möglichkeit, den Container zu starten. Daher habe ich den Befehl docker logs tracker1 verwendet, um die Protokollinformationen des Containers anzuzeigen. Nach genauerem Hinsehen die folgende Schnittstelle erschien und zeigte standard_init_linux.go: 195: Exec-Benutzerprozess verursachte „Exec-Formatfehler“ . Dieser Fehler bedeutet, dass die Ausführung des Benutzerprozesses einen Ausführungsformatfehler verursacht hat
Es ist auch das erste Mal, dass ich auf eine solche Situation stoße, aber ich bin auch schon einmal auf diese Situation gestoßen, als ich Docker in meiner eigenen virtuellen Linux-Maschine installiert und verwendet habe. Nachdem ich viele Male im Ozean des Blog-Wissens gewandert bin, habe ich es endlich geschafft Ich habe diese Situation gefunden. Der Kern des Problems besteht darin, dass sich die Architektur des Bildes von der Architektur meiner virtuellen Maschine unterscheidet
4. Die Lösung des Problems hängt letztendlich von einem Beitrag eines Internetnutzers ab, in dem erwähnt wird, wie der Docker-Befehl zum Anzeigen der Spiegelstruktur verwendet wird, Docker inspect morunchang/fastdfs , das hat das Problem wirklich gefunden, Sie können meinen FastDFS-Spiegel sehen. Die Architektur ist amd64
Ich habe die Architektur meines virtuellen Maschinensystems erneut überprüft und zur Abfrage den Befehl uname -a verwendet . Die Ergebnisse sind wie folgt: Sie können sehen, dass die Architektur meiner virtuellen Maschine aarch64 ist
Die Architektur der virtuellen Maschine und des Spiegelbilds sind unterschiedlich, sodass das obige Problem auftritt, da der Computer des Editors ein M1-Chip ist und bei der Installation der virtuellen Maschine nur das Architektursystem aarch64 ausgewählt werden kann
5. Der Editor ging also zur offiziellen Docker-Website, um die mit FastDFS verbundenen Bilder zu überprüfen, und stellte fest, dass die vom Editor installierten Bilder nicht mit der Architektur meines Systems übereinstimmten.
Aber am Ende hat der Redakteur immer noch ein FastDFS-Image gefunden, das auf der aarch64-Architektur verwendet werden kann.
Stellen Sie also die FastDFS-Umgebung wieder her, rufen Sie das Image ab und erstellen Sie den entsprechenden Container neu
Schließlich wurde der Container erfolgreich gestartet, es gab keine Flashback-Vorstellung und das Problem wurde gelöst
