dbhi / qus

qemu-user-static (qus) and containers, non-invasive minimal working setups

Home Page:https://dbhi.github.io/qus

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Restarting containers

megascrapper opened this issue · comments

How do I restart a stopped container? I tried docker restart <container_name> but the container exits immediately with the following error in the log:

standard_init_linux.go:219: exec user process caused: exec format error

Tried docker restart --platform <platfrom> <container_name> only to be greeted with unknown flag.

Looks like I figured it out: you have to re-run the qus containder before restarting yout emulated container.

@megascrapper thanks for updating, and I'm sorry for not being responsive.

The solution you commented sounds weird (although I won't discuss it works for you). I would be glad if you could provide the full list of commands you tried. Just in case you want me to try reproducing it on my RPi 3.

  1. List all the interpreters on a fresh boot.
  2. Register one or multiple interpreters with qus.
  3. Start a container.
  4. Restart a container.

On a fresh boot:

$ docker buildx ls
NAME/NODE DRIVER/ENDPOINT STATUS  PLATFORMS
default * docker
  default default         running linux/arm64, linux/arm/v7, linux/arm/v6

After running docker run --rm --privileged aptman/qus -s -- -p x86_64:

NAME/NODE DRIVER/ENDPOINT STATUS  PLATFORMS
default * docker
  default default         running linux/arm64, linux/arm/v7, linux/arm/v6, linux/amd64

After running qus all emulated containers started successfully.

My question then would be then whether it's possible to make the configuration persistent across reboots.

I also just stumbled upon this, that the configuration seems not to be persistent across reboots. What would be the recommended way to achieve this?

@megascrapper @dkadioglu with option -p the interpreters are loaded in memory. Therefore, it is not possible to make them persistent across reboots, per se. However, that is a common issue with many software tools. Typically, operating systems do have features such as systemd, to automatically init/restart/stop software. For instance, see https://stackoverflow.com/questions/52213399/setting-of-binfmt-misc-is-gone-after-rebooting.

dbhi/qus uses script register.sh, which is a wrapper around qemu-binfmt-conf.sh. The latter supports option --systemd. See https://github.com/umarcor/qemu/blob/series-qemu-binfmt-conf/scripts/qemu-binfmt-conf.sh#L218. Hence, it might be technically possible to execute qemu-binfmt-conf with options -s -p; however, I don't know how will that play with being executed on a container. In those use cases, it might be desirable to have qemu static binaries on the host, rather than using dbhi/qus images (see column "Dependency" in Tests).

Thanks for your answer and input!
I did a little more research and came up with the following:

  • add the qus container as dependency for the actual service, which needs it
  • as this won't work in case of a restart, also add another dependency, which removes registered interpreters beforehand
  • as I couldn't make it run at boot of the host (didn't invest much time to investigate), I created a systemd service, which calls docker-compose up on boot and docker-compose down on shutdown (all relevant data is in persistent volumes)

exemplary docker-compose.yml:

version: "3"
services:
   archcomprem:
     image: aptman/qus
     command: '-- -r'
     privileged: true
   archcompins:
     image: aptman/qus
     command: '-s -- -p x86_64'
     privileged: true
     depends_on:
       archcomprem:
         condition: service_completed_successfully
   service:
     ...
     depends_on:
       archcompins:
         condition: service_completed_successfully

exemplary systemd service file:

[Unit]
Description=Starts service on boot and removes on shutdown
Requires=docker.service
After=docker.service
[Service]
Restart=always
WorkingDirectory=/directory/where/docker-compose.yml/is
# Shutdown container (if running) when unit is started
ExecStartPre=/usr/bin/docker-compose -f docker-compose.yml down
# Start container when unit is started
ExecStart=/usr/bin/docker-compose -f docker-compose.yml up
# Stop container when unit is stopped
ExecStop=/usr/bin/docker-compose -f docker-compose.yml down
[Install]
WantedBy=multi-user.target

Maybe not optimal but, at least sufficient for my use case. Maybe helps others to achieve the same or come up with other ideas.