I’m trying to run an emulated raspberry pi inside a vm on fly but I’m running into issues exposing the shell for the machine when deployed on fly, even though it works when I run it locally.
I’m using a docker image (https://github.com/lukechilds/dockerpi) that uses qemu to emulate the rPi hardware and expose a shell to a user.
If I run the image locally with
docker run lukechilds/dockerpi, I get access to the shell for the emulated raspberry pi.
The image is running when I deploy it via fly machines, and I can see the expected logs in the monitoring tab of my dashboard. Yay, emulated raspberry-pi in the cloud.
However, when I ssh into the machine via
fly ssh console -a dioderaspberryapp, I’m not in the same process as when I run the container locally.
I can see the qemu process is running if I use command
I want to connect to the process that’s outputting the logs in the monitoring tab, the emulated terminal for the raspberry pi.
I think I might be missing something obvious, since it works pretty easily locally with just
docker run, and I can see the expected logs in the monitoring dashboard.
Any ideas on how I can access that specific process when I ssh into the machine?
I don’t think what you want is exactly possible.
A few points:
fly ssh console runs
sh like you saw - it’s essentially, SSH-ing in and starting a new process, not attaching to a currently running process.
- When launching on Fly, Fly.io is running ENTRYPOINT + CMD as defined in the container image (altho it converted the docker image to a VM, so it’s not actually running Docker). Fly usually runs the entrypoint+cmd as some PID > 1 (since Fly.io has it’s own init that’s running as pid 0 or 1 or something like that).
In any case, attaching to a process that’s running in a way that’s interactive doesn’t sound like a thing that’s possible (even outside of Fly). It’s more akin to running
docker exec -it... locally against a running Docker container - it doesn’t attach to the primary process being run, but instead runs a new process in the same container.
Okay thanks for the info! I think that’s enough info where I can start going down another path to build what I want.
Really was just wanting a sanity check to see if it was even possible going down this route! Thank you
So… perhaps change your ENTRYPOINT/CMD in your Dockerfile to the equivalent of
sleep 365d, and then when you ssh in, run the command that used to be listed as the ENTRYPOING/CMD?