`fly postgres attach` command fails

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?

staging-7-themes and db-staging-7-themes

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

1 Like

@ianduvall Could you try running fly doctor and paste the results?

% fly doctor
TEST STATUS
Agent PASS
Docker (local) PASS
Token PASS
Unix socket PASS

You have all of our attention now!

Try:

flyctl agent restart (this is voodoo and probably won’t do anything but do it anyways)

and then:

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).

2 Likes

No problem.

% 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 config.yml.

% 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!

1 Like