bug#64937: boot time on Linux

Bruno Haible writes: > Po Lu wrote: >> >> Both clock_gettime (CLOCK_BOOTIME, ... sysinfo fail with AVC denial >> >> errors and errno set to EACCESS. >> > >> > Was this inside Termux, or inside the Emacs app? >> >> Inside the Emacs app. > > Emacs does not have the following in

bug#64937: boot time on Linux

Natanael Copa wrote: > There are machines without RTC (Raspberry PI for example), and in > this case the time stamp may end up to be the same every reboot (if > correctly set up it should save the shutdown time for the reboot and set > time to this on next boot, but there is no guarantee).

bug#64937: boot time on Linux

Po Lu wrote: > >> Both clock_gettime (CLOCK_BOOTIME, ... sysinfo fail with AVC denial > >> errors and errno set to EACCESS. > > > > Was this inside Termux, or inside the Emacs app? > > Inside the Emacs app. Emacs does not have the following in AndroidManifest.xml, which Termux has:

bug#64937: boot time on Linux

Hi, I had a quick look at the thread, and I have a few comments. 1) it is openrc's bootmisc ( https://github.com/OpenRC/openrc/blob/86efc43d0e0d7569f5d2e7a58b8c461ac9f7dae8/init.d/bootmisc.in#L197) that creates /var/run/utmp. There is no guarantee that this exists. You can for example run emacs

bug#64937: boot time on Linux

Bruno Haible writes: > Po Lu wrote: >> Both clock_gettime (CLOCK_BOOTIME, ... sysinfo fail with AVC denial >> errors and errno set to EACCESS. > > Was this inside Termux, or inside the Emacs app? Inside the Emacs app. I'll try Termux soon: maybe the target SDK version is the culprit.

bug#64937: boot time on Linux

Po Lu wrote: > Both clock_gettime (CLOCK_BOOTIME, ... sysinfo fail with AVC denial > errors and errno set to EACCESS. Was this inside Termux, or inside the Emacs app? Bruno

bug#64937: boot time on Linux

Bruno Haible writes: > I wrote: >> > No, it isn't. The attached file, when compiled and run under Termux (which >> > doesn't have particular permissions), prints e.g.: >> > >> > from clock : 1691616762.476870660 = 2023-08-09 21:32:42.476870660 >> > from sysinfo: 1691616762.329261637 =

bug#64937: boot time on Linux

I wrote: > > No, it isn't. The attached file, when compiled and run under Termux (which > > doesn't have particular permissions), prints e.g.: > > > > from clock : 1691616762.476870660 = 2023-08-09 21:32:42.476870660 > > from sysinfo: 1691616762.329261637 = 2023-08-09 21:32:42.329261637 > > > >

bug#64937: boot time on Linux

On Thu, 10 Aug 2023 17:38:10 +0800 Po Lu wrote: > Natanael Copa writes: > > > 2) Even if it does exist, there is no guarantee that the timestamp is > > correct. There are machines without RTC (Raspberry PI for example), > > and in this case the time stamp may end up to be the same every reboot

bug#64937: boot time on Linux

Natanael Copa writes: > 2) Even if it does exist, there is no guarantee that the timestamp is > correct. There are machines without RTC (Raspberry PI for example), > and in this case the time stamp may end up to be the same every reboot > (if correctly set up it should save the shutdown time for

bug#64937: boot time on Linux

Paul Eggert writes: > On 2023-08-09 19:14, Po Lu wrote: >> This uses the uptime counter (which also results in an SELinux denial >> for me, but different Android distributions have SELinux policies of >> varying strictness), which cannot establish the precise time the system >> started > > Emacs

bug#64937: boot time on Linux

On 2023-08-09 19:14, Po Lu wrote: This uses the uptime counter (which also results in an SELinux denial for me, but different Android distributions have SELinux policies of varying strictness), which cannot establish the precise time the system started Emacs doesn't need a precise boot time.

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

bug#64937: boot time on Linux

Thorsten Kukuk wrote: > > What API do you suggest we use instead? > > For me clock_gettime works very well: > https://github.com/thkukuk/utmpx/blob/main/utmp-to-logind.md#determine-boot-time Now that I've implemented this method in gnulib's 'readutmp' module and built coreutils with that, I see