Tracked in Github Issues as https://github.com/canonical/cloud- init/issues/2423
** Bug watch added: github.com/canonical/cloud-init/issues #2423 https://github.com/canonical/cloud-init/issues/2423 ** Changed in: cloud-init Status: Confirmed => Expired -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to cloud-init. https://bugs.launchpad.net/bugs/1273255 Title: wait_for_url doesn't account for system clock being changed Status in cloud-init: Expired Bug description: 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. To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1273255/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : [email protected] Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
