The recent overhaul/rewrite of the 'readutmp' module is nearly complete:
It supports a system-independent API. It gets information from systemd
instead of /var/run/utmp when possible. It has fallbacks for the boot time.
It was tested with various desktop environments.
One thing is still missing though, and I haven't had time to look into it:
* Since /var/log/wtmp is meant to go away in the long run [1], how to
replace the read_utmp call of this file with systemd calls?
We have a read_utmp_from_systemd function. Shouldn't we have a
read_wtmp_from_systemd function as well?
What's the right replacement?
- wtmpdb ? [3]
- journalctl --list-boots ? [4][5]
- last ? [4]
The test case is the 'who' program from coreutils:
$ who /var/log/wtmp | grep -v pts/
Can we have a reasonable synthesis of
$ who /var/log/wtmp | grep -v pts/ | tail
bruno tty1 2023-06-30 09:03 (:0)
bruno tty1 2023-06-30 09:05 (:0)
bruno tty2 2023-07-08 23:42
bruno tty2 2023-07-08 23:49
bruno tty1 2023-08-26 01:57 (:0)
bruno tty1 2023-08-27 03:47 (:0)
bruno tty1 2023-08-27 19:37 (:0)
bruno tty1 2023-08-27 20:12 (:0)
bruno tty1 2023-08-28 18:42 (:0)
bruno tty1 2023-08-28 19:30 (:0)
$ journalctl --list-boots | tail
-9 9113e51371aa447fa4066b75a5b672b8 Fri 2023-06-30 09:03:06 CEST—Fri
2023-06-30 09:05:12 CEST
-8 bf6cd9a3cb5043efa0236176f01ad5c1 Fri 2023-06-30 09:05:35 CEST—Mon
2023-08-21 20:51:31 CEST
-7 4b5bc800085049039e78c143f76c82bc Sat 2023-08-26 01:57:20 CEST—Sun
2023-08-27 02:12:49 CEST
-6 19b5da9e34f84dd1989c2892431c0a20 Sun 2023-08-27 03:47:29 CEST—Sun
2023-08-27 19:24:14 CEST
-5 0665e0539d434f88a14f03b654f3832f Sun 2023-08-27 19:37:48 CEST—Sun
2023-08-27 20:11:34 CEST
-4 a9c53ad707bf4b72964f4ec6015be144 Sun 2023-08-27 20:12:10 CEST—Mon
2023-08-28 12:30:01 CEST
-3 aac7e9a36fd547979993d243fd3ffbef Mon 2023-08-28 18:35:37 CEST—Mon
2023-08-28 18:35:37 CEST
-2 d4d3ea3ad5ca4b2c99501c89023f2ca4 Mon 2023-08-28 18:38:40 CEST—Mon
2023-08-28 18:38:40 CEST
-1 3fda343a1c6a47e4aa2136a427bbc5a5 Mon 2023-08-28 18:42:03 CEST—Mon
2023-08-28 19:22:53 CEST
0 e0d1afceba004eff827723549f896edb Mon 2023-08-28 19:30:50 CEST—Sat
2023-09-09 13:09:01 CEST
$ last | head -n 33
bruno pts/19 :0 Sat Sep 9 12:35 still logged in
bruno pts/18 :0 Fri Sep 8 13:18 still logged in
bruno pts/17 :0 Tue Sep 5 22:19 still logged in
bruno pts/17 :0 Tue Sep 5 17:37 - 21:21 (03:44)
bruno pts/16 :0 Tue Sep 5 15:40 still logged in
bruno pts/15 :0 Tue Sep 5 15:10 still logged in
bruno pts/15 :0 Mon Sep 4 22:26 - 22:51 (00:25)
bruno pts/14 :0 Fri Sep 1 11:28 still logged in
bruno pts/13 :0 Fri Sep 1 02:08 still logged in
bruno pts/12 :0 Wed Aug 30 01:58 still logged in
bruno pts/15 :0 Tue Aug 29 20:46 - 01:58 (05:12)
bruno pts/14 :0 Tue Aug 29 19:19 - 01:58 (06:39)
bruno pts/12 :0 Tue Aug 29 19:19 - 01:58 (06:39)
bruno pts/7 :0 Tue Aug 29 15:19 still logged in
bruno pts/4 192.168.178.46 Mon Aug 28 21:05 still logged in
bruno pts/13 :0 Mon Aug 28 19:30 - 15:25 (1+19:54)
bruno pts/12 :0 Mon Aug 28 19:30 - 10:41 (15:10)
bruno pts/7 :0 Mon Aug 28 19:30 - 10:41 (15:10)
bruno pts/4 :0 Mon Aug 28 19:30 - 21:02 (01:31)
bruno pts/6 :0 Mon Aug 28 19:30 - 21:02 (01:31)
bruno pts/14 :0 Mon Aug 28 19:30 - 21:02 (01:31)
bruno pts/5 :0 Mon Aug 28 19:30 still logged in
bruno pts/3 :0 Mon Aug 28 19:30 still logged in
bruno pts/2 :0 Mon Aug 28 19:30 still logged in
bruno pts/10 :0 Mon Aug 28 19:30 still logged in
bruno pts/8 :0 Mon Aug 28 19:30 still logged in
bruno pts/1 :0 Mon Aug 28 19:30 still logged in
bruno pts/11 :0 Mon Aug 28 19:30 still logged in
bruno pts/9 :0 Mon Aug 28 19:30 still logged in
bruno pts/0 :0 Mon Aug 28 19:30 still logged in
bruno tty1 :0 Mon Aug 28 19:30 still logged in
reboot system boot 5.15.0-79-generi Mon Aug 28 19:30 still running
bruno pts/16 :0 Mon Aug 28 19:15 - 19:22 (00:07)
Bruno
[1] https://sourceware.org/bugzilla/show_bug.cgi?id=24492
[2] https://www.thkukuk.de/blog/Y2038_glibc_wtmp_64bit/
[3] https://github.com/thkukuk/utmpx/blob/main/utmp-to-logind.md
[4]
https://eng.libretexts.org/Bookshelves/Computer_Science/Operating_Systems/Linux_-_The_Penguin_Marches_On_(McClanahan)/12%3A_Linux_Systems_Security/5.17%3A_journalctl_last_Commands
[5]
https://unix.stackexchange.com/questions/408936/why-journalctl-list-boots-doesnt-match-what-uptime-and-who-b-report
