canonical / canonical/cloud-init
"socket.getaddrinfo" of "metadata.google.internal" fails on GCE
- Dominant language
- Python
- Stars
- 3.8k
- Forks
- 1.1k
- Avg merge
- 2d 23h
- Merged PRs (30d)
- 18
Description
This bug was originally filed in Launchpad as [LP: #1837106](https://bugs.launchpad.net/cloud-init/+bug/1837106)
Launchpad details
affected_projects = []
assignee = None
assignee_name = None
date_closed = None
date_created = 2019-07-18T19:40:41.411272+00:00
date_fix_committed = None
date_fix_released = None
id = 1837106
importance = medium
is_complete = False
lp_url = https://bugs.launchpad.net/cloud-init/+bug/1837106
milestone = None
owner = pkashsurya
owner_name = Prakash Surya
private = False
status = triaged
submitter = pkashsurya
submitter_name = Prakash Surya
tags = []
duplicates = []
_Launchpad user **Prakash Surya(pkashsurya)** wrote on 2019-07-18T19:40:41.411272+00:00_
When booting an Ubuntu 18.04 based image on GCE, we see the following messages in the log:
2019-05-30 00:05:27,818 - util.py[DEBUG]: Resolving URL: http://metadata.google.internal/computeMetadata/v1/ took 0.001 seconds
2019-05-30 00:05:27,818 - DataSourceGCE.py[DEBUG]: http://metadata.google.internal/computeMetadata/v1/ is not resolvable
2019-05-30 00:05:27,818 - util.py[DEBUG]: Crawl of GCE metadata service took 0.013 seconds
2019-05-30 00:05:27,818 - DataSourceGCE.py[WARNING]: address "http://metadata.google.internal/computeMetadata/v1/" is not resolvable
Further, the contents of "/run/cloud-init/instance-data.json" doesn't have any meaningful data.
What I've found is that, read_md() in DataSourceGCE.py will call util.is_resolvable_url() on the address "http://metadata.google.internal/computeMetadata/v1/", which results is calling socket.getaddrinfo() for "metadata.google.internal", and it's this socket.getaddrinfo() call that fails.
This failure appears to be due to the fact that "cloud-init.service" does not ensure it waits for DNS (i.e. "systemd-resolved.service") to be working before it runs. I say this because:
1. If I add "After=systemd-resolved.service" to the "cloud-init.service" definition, this failures goes away.
2. If I run "cloud-init init" after the system has booted up (i.e. after enough time has passed, such that DNS is working), the failure doesn't occur.
Contributor guide
Assessment
This issue has not been assessed yet.