Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Restarting containers #9

Open
megascrapper opened this issue Apr 3, 2021 · 7 comments
Open

Restarting containers #9

megascrapper opened this issue Apr 3, 2021 · 7 comments
Labels
question Further information is requested

Comments

@megascrapper
Copy link

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.

@megascrapper
Copy link
Author

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

@umarcor
Copy link
Member

umarcor commented Apr 14, 2021

@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.

@megascrapper
Copy link
Author

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.

@megascrapper megascrapper reopened this Apr 15, 2021
@megascrapper
Copy link
Author

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

@dkadioglu
Copy link

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?

@umarcor
Copy link
Member

umarcor commented Feb 22, 2022

@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).

@umarcor umarcor added the question Further information is requested label Feb 22, 2022
@dkadioglu
Copy link

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
question Further information is requested
Projects
None yet
Development

No branches or pull requests

3 participants