Which uptime implementation for the future?
Hello, There are current two "uptime" implementations with different behavior: 1. coreutils The GNUlib developers are of the opinion, that /proc/uptime is not correct, as the kernel does not count the time as uptime, in which a VM is stopped. I have no idea if the time where a VM is stopped should be really counted as uptime, I would say no. The problem with their implementation is, that we have several bug reports, that the uptime is wrong. Reason is, that they try to determine the boot time via timestamps from files, and if the machine has no RTC this time is most likely wrong. In other cases, the time does not get updated or the tools counts soft-reboots as real reboots. Feedback from last weeks All Systems Go! conference is, that they see the coreutils uptime behavior as bug. 2. procps-ng It's using /proc/uptime, which means it reports the uptime as the kernel sees it. Due to the problems with 1), shouldn't we switch to 2)? Regards, Thorsten -- Thorsten Kukuk, Distinguished Engineer, Senior Architect, Future Technologies SUSE Software Solutions Germany GmbH, Frankenstraße 146, 90461 Nuernberg, Germany Managing Director: Ivo Totev, Andrew McDonald, Werner Knoblich (HRB 36809, AG Nürnberg)
On Fri, 4 Oct 2024 15:11:58 +0200, Thorsten Kukuk via openSUSE Factory <factory@lists.opensuse.org> wrote:
Hello,
There are current two "uptime" implementations with different behavior:
1. coreutils The GNUlib developers are of the opinion, that /proc/uptime is not correct, as the kernel does not count the time as uptime, in which a VM is stopped. I have no idea if the time where a VM is stopped should be really counted as uptime, I would say no. The problem with their implementation is, that we have several bug reports, that the uptime is wrong. Reason is, that they try to determine the boot time via timestamps from files, and if the machine has no RTC this time is most likely wrong. In other cases, the time does not get updated or the tools counts soft-reboots as real reboots. Feedback from last weeks All Systems Go! conference is, that they see the coreutils uptime behavior as bug.
2. procps-ng It's using /proc/uptime, which means it reports the uptime as the kernel sees it.
Due to the problems with 1), shouldn't we switch to 2)?
As an end-user, *I* would expect uptime to report the duration since boot, whether the machine was available or not. IOW the time since the kernel started. I acknowledge that actual uptime (the time the machine was available and not sleeping) has value and now that I am aware I could imagine I want to see that too.
Thorsten
-- H.Merijn Brand https://tux.nl Perl Monger http://amsterdam.pm.org/ using perl5.00307 .. 5.37 porting perl5 on HP-UX, AIX, and Linux https://tux.nl/email.html http://qa.perl.org https://www.test-smoke.org
On Friday 2024-10-04 15:11, Thorsten Kukuk via openSUSE Factory wrote:
There are current two "uptime" implementations with different behavior:
1. coreutils The GNUlib developers are of the opinion, that /proc/uptime is not correct, as the kernel does not count the time as uptime, in which a VM is stopped. I have no idea if the time where a VM is stopped should be really counted as uptime, I would say no.
Possible definitions: 1. "up" is when it's not down, i.e. whatever abstract service you are measuring is responsive to requests and can execute them; this implies always measuring in monotonic time. 2. time delta since an event (e.g. boot), which has its own caveats: 2a. as measured with monotonic clocks' timestamps? 2b. as measured with wallclocks' timestamps? Some clocks can run slow relative to others (NTP time slew), some clocks can outright jump, and some can even jump _backwards_. The intuitive definition is 1. File timestamps are of the 2b variety, which, given the hardships just described, seem the worst of definition for an uptime metric. Or to put it differently, « What do you mean my uptime is minus 18 minutes? »
[adding coreutils ML] On 10/4/24 3:11 PM, Thorsten Kukuk via openSUSE Factory wrote:
1. coreutils The GNUlib developers are of the opinion, that /proc/uptime is not correct, as the kernel does not count the time as uptime, in which a VM is stopped. I have no idea if the time where a VM is stopped should be really counted as uptime, I would say no. The problem with their implementation is, that we have several bug reports, that the uptime is wrong. Reason is, that they try to determine the boot time via timestamps from files, and if the machine has no RTC this time is most likely wrong. In other cases, the time does not get updated or the tools counts soft-reboots as real reboots. Feedback from last weeks All Systems Go! conference is, that they see the coreutils uptime behavior as bug.
When was this last discussed on GNU mailing lists? {bug-gnulib,bug-coreutils,coreutils}@gnu.org Last activities I see there are from 2023 only. If there's a bug, I'm sure we'll be able to fix it. Have a nice day, Berny
Hi all, Am 04.10.24 um 15:11 schrieb Thorsten Kukuk via openSUSE Factory:
Hello,
There are current two "uptime" implementations with different behavior:
1. coreutils The GNUlib developers are of the opinion, that /proc/uptime is not correct, as the kernel does not count the time as uptime, in which a VM is stopped. I have no idea if the time where a VM is stopped should be really counted as uptime, I would say no. The problem with their implementation is, that we have several bug reports, that the uptime is wrong. Reason is, that they try to determine the boot time via timestamps from files, and if the machine has no RTC this time is most likely wrong. In other cases, the time does not get updated or the tools counts soft-reboots as real reboots. Feedback from last weeks All Systems Go! conference is, that they see the coreutils uptime behavior as bug.
The thing is that I don't care if suspend time is counted as uptime or not, but the implementation bug that they fail with non-rtc machines makes me opt for number 2)
2. procps-ng It's using /proc/uptime, which means it reports the uptime as the kernel sees it.
Also "busybox uptime" does it the same. And busybox is always right ;-) -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman
On 10/4/24 09:11, Thorsten Kukuk via openSUSE Factory wrote:
Hello,
There are current two "uptime" implementations with different behavior:
1. coreutils The GNUlib developers are of the opinion, that /proc/uptime is not correct, as the kernel does not count the time as uptime, in which a VM is stopped. I have no idea if the time where a VM is stopped should be really counted as uptime, I would say no.
I agree. When a VM is stopped it is not up, i.e. not usable. This is also consistent with Public CLoud behavior, a Public CLoud instance in a stopped state does not incur usage charges for the instance.
The problem with their implementation is, that we have several bug reports, that the uptime is wrong. Reason is, that they try to determine the boot time via timestamps from files, and if the machine has no RTC this time is most likely wrong. In other cases, the time does not get updated or the tools counts soft-reboots as real reboots. Feedback from last weeks All Systems Go! conference is, that they see the coreutils uptime behavior as bug.
2. procps-ng It's using /proc/uptime, which means it reports the uptime as the kernel sees it.
Due to the problems with 1), shouldn't we switch to 2)?
Thumbs up from me for the switch. Later, Robert -- Robert Schweikert MAY THE SOURCE BE WITH YOU Distinguished Engineer LINUX rjschwei@suse.com IRC: robjo
participants (6)
-
Bernhard Voelker -
H.Merijn Brand -
Jan Engelhardt -
Robert Schweikert -
Stefan Seyfried -
Thorsten Kukuk