bug#64937: boot time on Linux

Bruno Haible writes: > Po Lu wrote: >> > Also, I don't know how Android records boot time so I'll cc this to Po >> > Lu, the main developer for Emacs on Android. >> >> The boot time is off limits to user programs on Android, for security >> reasons. > > No, it isn't. The attached file, when

bug#64937: boot time on Linux

Po Lu wrote: > > Also, I don't know how Android records boot time so I'll cc this to Po > > Lu, the main developer for Emacs on Android. > > The boot time is off limits to user programs on Android, for security > reasons. No, it isn't. The attached file, when compiled and run under Termux (which

bug#64937: boot time on Linux

Paul Eggert writes: > [For those cc'ed, the thread's at .] > > On 2023-08-09 07:29, Bruno Haible wrote: > >> And on Alpine Linux, while /var/run/utmp is empty, its time stamp is >> essentially the boot time. >> The approach used by Emacs, namely to look at the

bug#64937: boot time on Linux

Paul Eggert wrote: > This patch does not address the problem for Alpine, nor I suspect for > Android. I suppose Alpine could use the timestamp of /var/run/utmp (or > is that /run/utmp?) but I don't know how 'configure' would reliably > detect it's being built or cross-built for Alpine. I'll cc

bug#64937: boot time on Linux

I wrote: > So, all approaches that compute the boot time through a subtraction are > going to be wrong in these scenarios. > > The better approach is really to read the boot time from a time stamp — > inside a file such as /var/run/utmp or /var/log/wtmp, or attached to > a file such as >

bug#64937: boot time on Linux

[For those cc'ed, the thread's at .] On 2023-08-09 07:29, Bruno Haible wrote: And on Alpine Linux, while /var/run/utmp is empty, its time stamp is essentially the boot time. The approach used by Emacs, namely to look at the time stamp of /var/run/random-seed,

bug#64937: boot time on Linux

More info about this problem: I wrote > I have a VM running in VirtualBox, that I booted 6 days ago, then "saved" > it (i.e. all the state gets frozen) and resumed it today around 20:30 UTC. > ... > So, both programs show a "boot time" that is just 5 hours ago, at a moment > when > the VM was in