After running fly ssh console --app <app-name> the connection completes but after a seemingly random duration the connection closes without explanation. I have been trying to get by using -C "<commands>" but that is a inconvenient and it would be nice to simply ssh into the machine(s) I need to. Is there a setting or configuration I need to just ssh with fly ssh console? Also, why can’t I just ssh into the machine(s) via regular ssh command like ssh user@ip ? Can someone point me in the right direction please?
Solution for my specific problem:
I figured out what was wrong. I was deploying a wasp app with wasp deploy fly deploy and there was a database migration that prevented start-production from running when it tried to start up. So it was stuck in a loop of attempting to run npm run start-production, failing, and then restarting the machine. I was able to ssh to the machine while it was attempting to run start-production but then the ssh connection would close when the machine restarted to attempt running the startup script again.
In case anyone runs into the same problem, I fixed the issue by modifying the Dockerfile in .wasp/build, replacing ENTRYPOINT ["npm", "run", "start-production"] with ENTRYPOINT ["sleep", "infinity"] then deploying to fly.io with fly deploy --dockerfile <path-to-dockerfile> --app <app-name> from the .wasp/build directory. Then I was able to mark the botched migration as rolled-back with npx prisma migrate resolve --rolled-back <failed-migration>
After that the ssh connection remains intact. I hope this helps if someone has the same issue.
Is there a setting or configuration I need to just ssh with fly ssh console?
I am trying to parse this part of your question. It originally sounded that you can SSH, but that you’re wanting the connection not to timeout. But this sounds like you’re now not connecting at all; would you clarify?
How long does a timeout take? Does it not timeout if you frequently type into the session? I am wondering if there’s a keep-alive feature (I am not sure if it uses the ssh on your machine, or if it uses its own, but it may be worth seeing if another flag can be utilised).
I bet your app is configured with auto_stop_machines = true. The reason your SSH session dies is because the machine shuts down due to inactivity; only HTTP connections made through the Fly proxy count for purposes of waking up and keeping up the machine; the SSH connection doesn’t count.
You can either set the machines in the app to not auto-stop, or, (dirty hack), throw some requests at the app so the machines stay up: while curl https://your-app.fly.dev; do sleep 30; done should do it. (Note though that if you have more than one machine, there’s no guarantee the requests will hit the machine you’ve SSHd into!).
I’m not sure why I worded it that way, I must have overlapped the next sentence with that one in my brain and didn’t catch it before posting. I essentially meant to ask is there a setting or configuration I need to set to keep the ssh connection open with fly ssh console? I figured out what was happening though, and I’ll explain in a reply to the initial post in case anyone runs into a similar issue. Thank you for your response.
I figured out what was wrong. I was deploying a wasp app with wasp deploy fly deploy and there was a database migration that prevented start-production from running when the tried to start up. So it was stuck in a loop of attempting to run npm run start-production, failing, and then restarting the machine. I was able to ssh to the machine while it was attempting to run start-production but then the ssh connection would close when the machine restarted to attempt running the startup script again.
In case anyone runs into the same problem, I fixed the issue by modifying the Dockerfile in .wasp/build, replacing ENTRYPOINT ["npm", "run", "start-production"] with ENTRYPOINT ["sleep", "infinity"] then deploying to fly.io with fly deploy --dockerfile <path-to-dockerfile> --app <app-name> from the .wasp/build directory. Then I was able to mark the botched migration as rolled-back with npx prisma migrate resolve --rolled-back <failed-migration>