I assume it does not work because the way SQLite does locking/wal writes is by using the same OS, and docker for Mac M1 is probably emulating complete second OS with a Linux kernel. I am getting strange results the process continues as if it can write to the database, but both inside of and outside of the container sqlite3 seems to show a frozen version of the file (not showing the most recent writes).
When Docker for M1 runs based amd64 containers, I think it uses QEMU to emulate a amd64 CPU on the arm based M1.īut the issue I have is that there is SQLite code running inside the container, writing to a DB file that should be persisted to the host disk (I assume via some sort of feature to share directories host->QEMU). I am running a container, sharing a directory from my host to the guest:ĭocker run -platform -v /m1-host-dir:/vol linux/amd64 ubuntu On macOS, to get it, use brew install util-linux rockylinux uses it by default and unfortunately on Debian/Ubuntu, the opposite choice has been done (cf ).My computer is a Mac M1, I have Docker Desktop installed. util-linux is a standard package distributed by the Linux Kernel Organization. PS: the column command used here is the one from util-linux not the one from BSD utils. $ docker-ps-arch -aĬONTAINER ID IMAGE COMMAND STATUS NAME ARCHĢ61767e38db2 hello-world "/hello" Exited (0) About an hour ago practical_moore linux/amd64ġ6e364572d08 18e5af790473 "/hello" Exited (0) 3 hours ago peaceful_lalande linux/arm64
They produce outputs close to the original commands and support options of docker container ls and docker image ls. To list the architecture of the containers, you can use the following "quick" query: for i in `docker ps -format "' |Ĭolumn -table -table-columns "REPOSITORY,TAG,IMAGE ID,SIZE,ARCH" -o ' ' -s $'\t' The reason for this is that bitfmt (which is the underlying mechanism sitting inside the linux kernel) will always try to recognize the architecture from the magic numbers of the elf and will start the the emulation if the magic number is recognized. It should be noted that the "Architecture" flag on the image will not prevent a single process inside the image, which is compiled for a different architecture than the flagged one to run. Any of the containers that will run the image will be associated (trough the image) with this flag. The targeted architecture is determined from the "Architecture" flag on the image which was set when the image was build. Though the recognizing of the architecture is more related to the process, there is still information about the targeted architecture of the docker image. The mechanism for emulation is using the information in the elf to recognize the architecture for which the process is build, and if the architecture of the binary differs from the architecture of the CPU, it starts the qemu emulation. This is true also for Docker running on amd64 CPU, when the image is build for arm64, and the whole mechanism is explained in this SO
0 kommentar(er)
