SSH to machine?

Trying to check out the new machine functionality:

$ fly m run -a dev-aris-machine ubuntu:jammy-20220801

Searching for image 'ubuntu:jammy-20220801' remotely...
image found: img_589kp9o60jkpoj2e
Image: registry-1.docker.io/library/ubuntu:jammy-20220801
Image size: 30 MB
Success! A machine has been successfully launched, waiting for it to be started
 Machine ID: 0e286072f65186
 Instance ID: 01GBAX5K50EEHQEYRYE22RM5QM
 State: created
Machine started, you can connect via the following private ip
  fdaa:0:50fa:a7b:a15f:eee3:4671:2

$ fly config -a dev-aris-machine save

Wrote config file fly.toml

$ fly ssh console --verbose
Connecting to [fdaa:0:50fa:a7b:a15f:eee3:4671:2]...⣯
Error error connecting to SSH server: connect tcp [fdaa:0:50fa:a7b:a15f:eee3:4671:2]:22: operation timed out

Should this work? If not, what should I do instead?

Bonus issue: fly ssh console ignores ctrl-c.

It looks like this might be specific to the ubuntu image you’re using: I reproduced this by deploying that image with a machines app.

When I deployed the ubuntu image, while I didn’t get the error that you did, it did hang at the shell prompt and couldn’t be interrupted with ctrl-c.

When I deployed flyio/hellofly to another machine on the same app, I was able to get a shell and run commands.

Checking the logs for the app, I could see that jammy didn’t stay running for very long.

I decided to give it a bit more memory (I went with 2GB but you might be able to use less) and it worked! So maybe that’s also the issue you’re facing :sweat_smile:

Hey, so quick update --I ran into the same hanging behavior you did after a few minutes. So that might not be the issue here.

In any case, I’d definitely recommend taking a look at the instance logs with fly machines status.

As a workaround, you might be able to get the information you need by passing your command to fly ssh console -C "your command"

Hi Eli, thanks for the response and the fly machine status suggestion!

The machine immediately dies for reasons unknow:

$ fly m start 0e286072f65186
0e286072f65186 has been started

$ fly m status 0e286072f65186
Machine ID: 0e286072f65186
Instance ID: 01GBAX5K50EEHQEYRYE22RM5QM
State: stopped

VM
  ID            = 0e286072f65186
  Instance ID   = 01GBAX5K50EEHQEYRYE22RM5QM
  State         = stopped
  Image         = registry-1.docker.io/library/ubuntu:jammy-20220801
  Name          = spring-violet-5635
  Private IP    = fdaa:0:50fa:a7b:a15f:eee3:4671:2
  Region        = sjc
  Process Group =
  Memory        = 256
  CPUs          = 1
  Created       = 2022-08-25T16:25:38Z
  Updated       = 2022-08-26T19:57:13Z
  Command       =

Event Logs
STATE   	EVENT	SOURCE	TIMESTAMP                    	INFO
stopped 	exit 	flyd  	2022-08-26T15:57:13.557-04:00	exit_code=0,oom_killed=false,requested_stop=false
started 	start	flyd  	2022-08-26T15:57:10.881-04:00

The machine is stopped ~3 seconds after being started. This is the official and latest Ubuntu 22.04 image, so I’d expect this to Just Work, unless I’m doing something wrong. Happy to provide any other debugging info requested, but this should be wholly reproducible with: fly m run -a <any machine app> ubuntu:jammy-20220801.

Hi @aris,

VMs running on Fly.io need to run a long-lived process in order to stay running. A base container image like ubuntu has a default command of bash, which will exit immediately.

If you want to keep this container running just to interact with it through SSH, you can add a command like sleep infinity to keep it running forever:

fly m run -a dev-aris-machine ubuntu:jammy-20220801 sleep infinity

Hope this helps!

1 Like

Thanks! It’s clear that “app” lifecycle depends on, well, the app. By dropping down to the “machine” level, I thought I’d have control of the lifecycle and wouldn’t need a process to keep the machine alive.

Adding a long running process keeps the machine up, after which ssh works as expected!

Three bits of feedback for the Fly.io team:

  1. As mentioned, fly ssh should respect ctrl-c.
  2. Please add a README file to /.fly, as any DevOps/SRE type who runs ps will see the hallpass binary and have questions!
  3. fly ssh pops an sh shell - could this default to bashash (for images like Alpine) → sh?

With multiple running machines, fly ssh picks one at random (or deterministically) - is this a bug or a feature?

It’s nice that you don’t need to pass a machine ID argument when there’s only a single machine, but this might be a bit of a surprise when running multiple machines that aren’t necessarily identical.

Perhaps an extra line of output on connect, something like: X machines running for app my-app, connecting to <oldest|newest|randomest> machine 1234.