Code review comment for ~samgilson/cloud-init:cloud-init-analyze-boot

Revision history for this message
Sam Gilson (samgilson) wrote :

Keep in mind I had created this VM earlier in the day, hence why all the timestamps are so far off the current time.
> This is very interesting. I created an Ubuntu 18.04:latest VM on Azure and did
> the same checks as you, and here is what I got.
> cat /var/log/cloud-init.log | grep "running 'init-local"
> 2019-06-24 18:59:34,735 - util.py[DEBUG]: Cloud-init v.
> 19.1-1-gbaa47854-0ubuntu1~18.04.1 running 'init-local' at Mon, 24 Jun 2019
> 18:59:34 +0000. Up 22.97 seconds.
>
> systemctl show -p UserspaceTimestamp
> UserspaceTimestamp=Mon 2019-06-24 18:59:22 UTC
>
> systemctl show -p ExecMainStartTimestamp cloud-init-local
> ExecMainStartTimestamp=Mon 2019-06-24 19:43:33 UTC
>
> systemctl show -p ActiveEnterTimestamp cloud-init-local
> ActiveEnterTimestamp=Mon 2019-06-24 19:43:33 UTC
>
> systemctl show -p InactiveExitTimestamp cloud-init-local
> InactiveExitTimestamp=Mon 2019-06-24 18:59:30 UTC
>
> cloud-init analyze boot
> -- Most Recent Boot Record --
> Kernel Started at: 2019-06-24 18:59:11.739511
> Kernel ended boot at: 2019-06-24 18:59:22.125180
> Kernel time to boot (seconds): 10.385669
> Cloud-init start: 2019-06-24 18:59:30.426426
> Time between Kernel boot and Cloud-init start (seconds): 8.301246
>
> In my case, the InactiveExitTimestamp and the timestamp shown in cloud-
> init.log are the closest together (still not correct), with the ActiveEnter
> and ExecMainStart timestamps being very far off the mark. I am not really
> certain as to why the ActiveEnter and ExecMainStart are so far off in this
> case.

« Back to merge proposal