SSHing into a machine shows a different terminal than running docker locally

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 ps -a

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?

1 Like

I don’t think what you want is exactly possible.

A few points:

  1. 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.
  2. 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.

2 Likes

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 :slight_smile:

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?

3 Likes