trying to setup cloud sql proxy following the instructions here: https://cloud.google.com/sql/docs/postgres/connect-auth-proxy#unix-sockets and get this error:
/Library/Google/google-cloud-sdk/bin/cloud-sql-proxy project:region:instance --unix-socket /Library/Google/google-cloud-sdk/cloudsql
2023/05/08 13:23:34 Authorizing with Application Default Credentials
2023/05/08 13:23:35 The proxy has encountered a terminal error: unable to start: [project:region:instance] Unable to mount socket: listen unix /Library/Google/google-cloud-sdk/cloudsql/project:region:instance/.s.PGSQL.5432: bind: invalid argument
checked that I have enabled cloud sql admin API and that i have permissions to connect. macos ventura.
cloud-sql-proxy -v
cloud-sql-proxy version 2.2.0+darwin.amd64
netstat -vanp tcp | grep 5432 shows me empty output
how can i fix?
Hi @morpheus,
You may want to check this debugging steps for Cloud SQL Auth proxy:
See the Connecting Overview page for more information on connecting to a Cloud SQL instance, or the About the Proxy page for details on how the Cloud SQL Proxy works.
You can also get in touch with Google Cloud Support if the above debugging doesn't work.
Before trying to check the source code may I ask if it is possible to use TCP sockets instead of Unix in your case? Are there some compelling reasons to use the Unix sockets implementation? It can be a bug for sure and it has to be fixed but for a time being can you try the TCP sockets. Of course if it is acceptable by the app design.
Thanks
Using ports/TCP sockets makes sense when you control the port use on the box and you're only trying to accomplish one thing. If you are setting up a service to be used by many people, you would allocate a fixed port to it, document it in /etc/services, etc., and it would run predictably.
However, if you have ad-hoc work, and say "Hmm... let's use this port..." you first need to check to make sure it's not in use, then you need to race to grab it before it is, handle failures when something grabs it before you, pick another port and repeat.
Such logic works fine when you're the only person on the box and you're not running multiple scripts which wrap this behavior. But when there are other people or other processes, this turns into a mess.
Unix socket dirs, named by the PID of the process, are a reliable way to get a unique connection which won't step on anyone or anything else. TCP sockets are designed for fixed services and can be exploited when you are one person on your own box and not doing much on it. For the proxy tools to work for real work or on shared machines, the right approach is --unix-socket.
And that is currently broken/unreliable due to the naming choices made by the socket code. There's a 108 character limit to unix socket names. An instance name, which can be up to 98 chars for Cloud SQL, plus the socket name and any prefix dir is just sometimes not going to work. AlloyDB, which uses cluster and instance in the dir name is comically designed to fail on all but the shortest names.
The proxy tools need a --socket-alias parameter to allow a short string to use instead of the long ones currently being used. Alternatively, the current behavior could be abandoned and a short, random, unique string could be used, but adding an option seems less likely to break anyone's existing scripts.
LinkedIn
Twitter
