canonical
wait_for_url doesn't account for system clock being changed
This bug was originally filed in Launchpad as LP: #1273255
Launchpad details
affected_projects = [] assignee = None assignee_name = None date_closed = None date_created = 2014-01-27T14:55:58.869097+00:00 date_fix_committed = None date_fix_released = None id = 1273255 importance = medium is_complete = False lp_url = https://bugs.launchpad.net/cloud-init/+bug/1273255 milestone = None owner = smoser owner_name = Scott Moser private = False status = confirmed submitter = smoser submitter_name = Scott Moser tags = [] duplicates = []
Launchpad user Scott Moser(smoser) wrote on 2014-01-27T14:55:58.869097+00:00
wait_for_url takes a 'max_wait' input, and then does: start = time.time() ... now = time.time()
The problem is that when this runs early in boot, ntp (or anything else really) might have set the clock backwards.
I'm looking at a console log that shows: 2014-01-27 14:46:24,743 - url_helper.py[WARNING]: Calling 'http://169.254.169.2 4/2009-04-04/meta-data/instance-id' failed [-16620/120s]: request error [(<urll compat_monitor0 console
Ie, the clock got set back 17000 seconds or something.
Asking in # python, I was told that in python3.3 I could use 'time.monotonic'.
In python 2.X, it seems that reading /proc/cpuinfo might be my only option.
I think this probably affects other areas of the code as well, such as reporting time for each stage to run, etc.
