In my head there are a few possibilities here: a.) azure correctly guessed that I was going to launch an instance and "pre-provisioned" it a week before I did it. this seems unlikely to me for a number of reasons, but I could be convinced that if this happened, everything is working as designed. b.) the kernel 'uptime' is only never-decreasing, but does not guarantee there are no jumps. Then, this is working as advertised.
My problem with 'b' is that (now) python3's monotonic clock agrees seems based on uptime: $ cat /proc/uptime ; python3 -c 'import time; print(time.mon otonic())' 771486.80 1542571.64 771486.825732702 python's documentation in pep 418 [1] says: Monotonic clock, i.e. cannot go backward. It is not affected by system clock updates. [1] https://www.python.org/dev/peps/pep-0418/#time-monotonic I would argue that all evidence points to the python.monotonic() output being affected by system clock updates(). (I don't have a output before that jump, so I clearly can't definitively say that, but it is a very strong coincidence otherwise). -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1880704 Title: jump in kernel clock during boot on azure To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1880704/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
