On Wed, 8 May 2024 at 09:21:35 +1000, Craig Small <csm...@debian.org> wrote:
> I can only speak for w. It currently prefers what it gets from
systemd or
> elogind, effectively
> iterating over the sessions coming from sd_get_sessions() if sd_booted()
> returns true.
>
> If sd_booted() returns false, then it uses the old utmp/utmpx files for
> now. Besides the Y2038
> issue, the utmp "API" is pretty awful with things like errors pretty much
> undetectable. There is also
> the problem about who (e.g. which process) should be writing to those
files
> as you have pointed out
> in your email.
>
> For now w/uptime will use utmp as a fallback, but I'll be happy if this
> gets updated to something better; it's a low-priority
> for me because systemd/elogind do what I need most of the time.
Thanks for explaining.
For last(1) my concern is that it will be helped to keep the original
last(1) for back-compatibility to read old wtmp files. For w(1), utmp
is only about current sessions, so there is no need to keep years-old
utmp files. Unlike last(1), there is no something like `w -f /run/utmp'.
Actually, one can run `last -f /run/utmp', and it provides output
similar to w(1)'s except missing something like process and CPU times
for each user. And as pointed out by you, w(1) currently already prefer
using infos from systemd/elogind instead of reading from utmp.
So I now think w(1) may be little need to keep the ability to read from
utmp and am also happy to it can change to use something better.
Regards,
Jun MO
