[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#65255: uptime's boot time is inconsistent after VM sleep & resume
|
From: |
Bruno Haible |
|
Subject: |
bug#65255: uptime's boot time is inconsistent after VM sleep & resume |
|
Date: |
Sun, 13 Aug 2023 01:00:37 +0200 |
On the following platforms:
- Linux (that includes glibc-based systems, Alpine Linux, Raspbian),
- NetBSD,
- Cygwin,
- Minix,
the "up" duration is inconsistent after the VM in which the OS is running
has been
1. put into sleep / saved / pause mode (terminology depends on the
hypervisor),
2. resumed,
3. a date bump has been done in the VM (either automatically or manually).
VM sleep and a date adjustment after resume is a common operation, as can
be seen
- from the fact that it's automatic in VirtualBox machines with the
"guest extensions" installed [1],
- from the fact that it's automatic in KVM [2],
- from the fact that it's automatic in Haiku as guest,
- from a remark in the libvirt documentation [3],
- from stackoverflow questions such as [4].
After such a VM sleep and a date adjustment, coreutils' "uptime" is
inconsistent in three ways:
* On Linux, the displayed "up" duration includes active time and
hardware suspend time [5], but excludes VM sleep time.
Such a figure is not useful for estimating the boot time, since
(time now) - (that "up" time) is not the boot time.
It is also not useful for estimating when e.g. a file system check
would be necessary on file systems without a journal, or how much
electricity was consumed — since the hardware suspend time was included.
So this figure is useless.
* The displayed "up" duration is inconsistent with the boot time displayed
by "who -a". (Since the Gnulib module 'readutmp' makes efforts to find
the boot time in a way that does not change when the date is adjusted.)
* The behaviour is inconsistent among platforms: On platforms which have
a /proc/uptime file, the displayed "up" time _excludes_ VM sleep time.
On the other platforms it _includes_ VM sleep time.
Seen on Linux (Fedora Rawhide, Alpine Linux 3.18, Raspbian), NetBSD 9.3,
Cygwin 2.9.0, Minix 3.3.
I see this as a bug. Find attached a fix for this bug. I'll provide a NEWS
entry afterwards, that summarizes the changes in coreutils + gnulib on the
various platforms.
Bruno
[1]
https://docs.oracle.com/en/virtualization/virtualbox/6.1/user/guestadditions.html#4.1.-Introduction-to-Guest-Additions
[2] https://bugzilla.redhat.com/show_bug.cgi?id=1115340
[3]
https://libvirt.gitlab.io/libvirt-appdev-guide-python/libvirt_application_development_guide_using_python-Guest_Domains-Lifecycle-Save.html
[4] https://serverfault.com/questions/334698/
[5] This is indicated by glibc's <bits/time.h>:
/* Monotonic system-wide clock that includes time spent in suspension. */
# define CLOCK_BOOTTIME 7
I also verified this on a laptop.
0001-uptime-Include-VM-sleep-time-in-the-up-duration.patch
Description: Text Data
- bug#65255: uptime's boot time is inconsistent after VM sleep & resume,
Bruno Haible <=