GNU bug report logs - #65255
uptime's boot time is inconsistent after VM sleep & resume

Previous Next

Package: coreutils;

Reported by: Bruno Haible <bruno <at> clisp.org>

Date: Sat, 12 Aug 2023 23:01:02 UTC

Severity: normal

Done: Paul Eggert <eggert <at> cs.ucla.edu>

Bug is archived. No further changes may be made.

Full log


Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Bruno Haible <bruno <at> clisp.org>
To: bug-coreutils <at> gnu.org
Subject: uptime's boot time is inconsistent after VM sleep & resume
Date: Sun, 13 Aug 2023 01:00:37 +0200
[Message part 1 (text/plain, inline)]
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 (text/x-patch, attachment)]

This bug report was last modified 1 year and 362 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.