I'm getting a lot of errors intermittently from Cloudant, when I post several thousand ~1000-character documents 10 at a time to _bulk_docs, from a Node app running on my local machine:
Error: getaddrinfo ENOTFOUND samdutton.cloudant.com
What does this error mean?
I've found a few similar problems online, but any suggestions how to avoid this error?
"getaddrinfo" represents your machine's inability to use DNS to find an IP address for the domain name "samdutton.cloudant.com". Can you confirm that your machine is able to resolve this DNS record correctly by doing
dig samdutton.cloudant.com
or
nslookup samdutton.cloudant.com
from your command line?
Related
I'm using nodejs with MongoDB server using mongoose, whenever I try to run my server, it won't connect to my database. After sometime above log is seen on CMD. My cluster name is merncluster here!!
Is there any solution to this, I've searched a lot, still can't find proper solution to this, this keeps happening all the time.
You may need to whitelist your IP address in MongoDB Atlas.
Adding 8.8.8.8 to my connection to the internet works for me.
Components
GKE
Helm v3
Terraform
Note: The below error is raised, BUT IF i keep doing terraform apply/delete multiple times, it would somehow auto-resolve. I am making use of Google Cloud Console so there is no chacne of my Internet messing things up.
Error Type 1:
Error: Error reading ComputeNetwork "projects/foo/global/networks/bar-network": Get https://www.googleapis.com/compute/v1/projects/foo/global/networks/bar-network-e4l6-network?alt=json: dial tcp [1111:2222:4003:c03::5f]:443: connect: cannot assign requested address
Error Type 2:
Error reading Service Account "projects/foo/serviceAccounts/bar-sa#foo.iam.gserviceaccount.com": Get https://iam.googleapis.com/v1/projects/foo/serviceAccounts/example-cluster-sa#dravoka2.iam.gserviceaccount.com?alt=json&prettyPrint=false: dial tcp [1111:2222:4003:c04::5f]:443: connect: cannot assign requested address
Error Type 3:
Error: Error retrieving available container cluster versions: Get https://container.googleapis.com/v1beta1/projects/foo/locations/us-central1-c/serverConfig?alt=json&prettyPrint=false: dial tcp [1111:2222:4003:c03::5f]:443: connect: cannot assign requested address
Error Type 4:
Error reading instance group manager returned as an instance group URL: "googleapi: Error 404: The resource 'projects/foo/zones/us-central1-c/instanceGroupManagers/gke-bar-main-pool-8c2b8edd-grp' was not found, notFound"
I don't understand why it popsup randomly, and when I re-run the same terraform apply/delete it magically works fine!
Any guidance would help.
I had this exact same problem, and after several hours of looking at it in more detail - i think I know what is happening and how to work around it. Since implementing the following workaround, I've had 100% success rate in apply/destroy operations.
Problem:
For some reason, Terraform is accepting the AAAA (IPv6) record over the A record. You can see this in the error response as the record for the *.googleapis.com is an IPv6 address. As Google Cloud Console doesn't have IPv6 enabled, this is why you're getting this error. It seems this is a problem with Go, rather than Terraform itself based on the searches I did for similar errors.
Solution:
Short of changing the source code in Terraform, you can instead modify your /etc/hosts file to respond with an IPv4 address for each of the APIs Terraform calls. As the Cloud Shell is hosted on Google Cloud, you can use the private.googleapis.com range (199.36.153.8/30). To automate this, just put the following in your .customize_environment file in your home directory:
export APIS="googleapis.com www.googleapis.com storage.googleapis.com iam.googleapis.com container.googleapis.com cloudresourcemanager.googleapis.com"
for i in $APIS
do
echo "199.36.153.10 $i" >> /etc/hosts
done
For reference, I created an issue in the Google provider to track it.
We have a problem in only one of our servers hosted at Amazon (the development server).
The problem happens when doing a curl request to a specific domain, by running this:
> curl https://api.plivo.com
Results in:
curl: (51) SSL: no alternative certificate subject name matches target host name 'api.plivo.com'
I did some research and found out that it might be a problem with the server's certificate, however if I try this from any other server it works fine, same on my local machine.
So I'm thinking that this might be a cache issue from curl? I tried reinstalling it, updating it, but no dice.
I'm almost creating a new dev machine because of this, because it's blocking us from using this service.
To summarize from the comments:
The good and the bad system actually accessed different servers which were configured with different certificates. That's why it failed on one system but not on the other.
The reason for this difference was that the bad system had an entry in /etc/hosts which was used instead of asking the DNS server.
The problem was found by comparing the output of curl -v and realizing that the shown target IP address was different.
The problem was fixed by removing the old entry in /etc/hosts so that it now queries the DNS server and gets the correct IP address of the server.
We access our database that is in SQL Azure, and every so often we hit this error while trying to connect. We connect from a corporate network, using SSMS or API.
The weird part is how it always successfully and instantly connects on retrying. We retry just 1 second after and it works.
We saw that the DTU Usage % was high and scaled our server up, but that did not help. We have employed a SqlAzureRetry policy while accessing the database from our API, which seems to be helping in mitigating the issue - but the root cause is still not identified.
Has anyone employed a configuration or strategy or faced a similar issue? (the underlying provider failed to open / network path not found).
Thanks!
The solution was to change the format of the server name to use TCP:
tcp:servername.database.windows.net,1433;
Also, if you're connecting from code, you should change to the above format in your connection string.
I seem to be having some issues with my domain controller when trying to resolve hostnames using dns. It does seem to work but it always takes a couple of attempts, even if its a hostname i have already resolved. I have been noticing it with webpages and downloads.
Here is a nslookup test i did
C:\Users\chris.townsend>nslookup abc.com
Server: dc.example.com
Address: 192.168.101.20
DNS request timed out.
timeout was 2 seconds.
*** Request to dc.example.com timed-out
C:\Users\chris.townsend>nslookup abc.com
Server: dc.example.com
Address: 192.168.101.20
Non-authoritative answer:
Name: abc.com
Address: 199.181.132.250
Some sites it works first time and some it takes a couple more. I cant seem to figure it out and its the same on all the systems in our office. Restarting and /dnsflush dont seem to make any diffence either.
Can anyone suggest anything?
just incase anyone else has this same issue : this is what we found out it was - we use a watch guard router and it seemed to be proxies causing this issue