Trying to attach a postgres db to my app and the command fails with the following error:
% fly postgres attach --app app-name --postgres-app db-app-name
Running flyadmin database-list
Error error connecting to SSH server: dial: lookup <db-app-name>.internal. on fdaa:0:44cb::3: read udp [fdaa:0:44cb:a7b:bea:0:a:0]:18147: i/o timeout
Any ideas on how to resolve this?
Hey there, what is the name of the app and postgres-app you’re looking to attach?
Good deal, try giving this a go:
fly postgres attach --app staging-7-themes --postgres-app db-staging-7-themes
To clarify, that’s what I did run originally. I just omitted the app and pg app names from the original question.
Ahh ok, that makes sense. We have had some known intermittent issues with SSH that can cause some weirdness. Just to rule that out, could you try running the command a couple times to see if anything changes?
I’ve run it periodically over the past few hours. I also setup WireGuard a few hours ago, would that cause this issue?
Taking a deeper look, will get back to you ASAP.
@ianduvall Could you try running
fly doctor and paste the results?
% fly doctor
Docker (local) PASS
Unix socket PASS
You have all of our attention now!
flyctl agent restart (this is voodoo and probably won’t do anything but do it anyways)
flyctl dig txt _apps.internal
Do you see a list of apps? Or get an error?
% flyctl dig txt _apps.internal
Error get app: Could not resolve App
Ok, that’s not weird, that just means you’re running it from a directory other than the one your
fly.toml is in. I don’t know the name of your app, but
flyctl -a my-app-name dig txt _apps.internal should work (or give us a more enlightening error).
(We’re working on automating all this troubleshooting stuff right now, so, thanks for helping us guinea-pig it).
% fly dig txt -a staging-7-themes _apps.internal
Error connect tcp [fdaa:0:44cb::3]:53: operation timed out
So that’s weird. Are you by any chance on a VPN, or on a network that filters UDP?
If you’re adventurous, a next thing you can try here is:
flyctl agent stop
vi ~/.fly/config.yaml # delete everything under the wire_guard_state key
flyctl -a staging-7-themes dig txt _apps.internal
… which will force flyctl to make a new WireGuard config for you.
Assuming you meant
% flyctl -a staging-7-themes dig txt _apps.internal
;; opcode: QUERY, status: NOERROR, id: 52788
;; flags: qr rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;_apps.internal. IN TXT
;; ANSWER SECTION:
_apps.internal. 5 IN TXT "db-prod-7-themes,db-staging-7-themes"
Well! We fixed the WireGuard thing. (The most recent
flyctl has a single command that resets your WireGuard, so you don’t ever have to touch
config.yml, and should soon do so preemptively so this just doesn’t come up at all).
We spotted an issue on our backend with your instance; a cleanup script may have fired in between the time we pulled the container for your db instance and the time your container started up, which may have zapped its network interface. Shaun I think resolved that?
Looks like I was able to attach the db to my app successfully! Thanks for the help!