Hi Kevin,
On Mon, Aug 18, 2025 at 12:28:40PM +0100, Kevin Chadwick wrote:
> On 17/08/2025 20:25, Andreas Messer wrote:
> > :
> >> I have a version that removes --enable-systemd that I will build for
> >> experimental.
> >>
> >> Can you both test?
> > I upgraded to excalibur today, worked flawlesly despite
> > mate-power-manager was uninstalled and not upgraded. (Just writing
> > E-Mail from this machine). I have now installed coreutils
> > 9.7-3devuan2 and did not observe any issues so far.
>
> I'm confused by that bug report and don't want to read it again. Does the who
> output issue only affect systemd systems?
TL;DR The #904 'who' issue in Devuan was not about the output, but if
you don't use elogind it would have been affected by #900 for
console logins.
I'm sorry my bug reports weren't clear enough! It probably doesn't help
that I spun bug #904 off bug #900. Let me tell the story of both bugs.
I am going to talk about a bunch of things here for context but the
subject of bugs 900 and 904 is specifically _current sessions_, aka what
you get from w and who.
Here is how things used to work:
A) /run/utmp: current sessions, read with w, who, users
B) /var/log/wtmp: past and current logins and reboots, read with last
C) /var/log/btmp: failed logins, read with lastb
D) /var/log/lastlog: the last time someone logged in
All the above used the record format struct utmp(5).
The seconds field in struct utmp was a signed 32-bit integer (int32_t),
which limited the recordable year to 2038.
Debian jumped on a plan to scrap ALL of the above, both the writing and
the reading, with separate sets of tools that dealt in 64-bit seconds
(t64) at the same time as a general ABI upgrade in Debian to 64-bit
time_t:
A) systemd (or elogind) session records for current sessions. These were
already recorded on relevant systems. I guess they'd have been
accessible by 'loginctl'. These are the type of sessions relevant to
bugs 900 and 904. The 'w', 'who' and 'users' commands in Debian trixie
have been changed to query these session records. More about this later.
B) wtmpdb and its helper, libpam_wtmpdb, backed by an sqlite database
for recording past logins and reboots. (I fixed some issues I was
concerned about with this package and ended up becoming its maintainer
in Debian.) I recomend appending this to your upgrade command line from
Daedalus to make sure the wtmp file conversion happens automatically,
with 'apt full-upgrade wtmpdb' as it is only automatically installed on
new installations.
C) btmp was not replaced; lslogins is the recommended alternative.
D) lastlog2 is the recommended alternative.
How do we now query current login sessions?
-------------------------------------------
1. w
In Debian, the 'w' command provided by the 'procps' package was the
first to be changed to use the session data recorded by systemd or
elogind. 'w' falls back to looking at the data recorded in utmp if these
aren't present, which is great if you don't use systemd or elogind, e.g.
you use seatd or nothing. Unfortunately, due to the Debian purge, not
everything still wrote to utmp, including logins on the virtual console,
although ssh sessions continued to be logged.
The way the 'procps' package queried these systemd-style login session
records was with libsystemd0, which is not systemd or even part of
systemd but some helper functions for interacting with the systemd
ecosystem.
Devuan wishes to avoid core packages linking with 'libsystemd0',
bringing it in unavoidably to systems that otherwise don't need it,
therefore procps is forked in Devuan not to link with libsystemd0.
Bug #900 noted that the lack of systemd/elogind integration for procps
meant meant 'w' did not show virtual console sessions because the
'login' command had stopped recording them in utmp. This was fixed by
adjusting the 'util-linux' fork in Devuan to restore the *recording* of
current sessions in /var/utmp by the login(1) command.
Some types of login may still not be shown by 'w' that otherwise would
on a systemd system but virtual console logins and ssh logins will.
2. who, users
In Debian, the 'who' and 'users' commands provided by the 'coreutils'
package were more recently changed to link with libsystemd0 and query
the systemd/elogind data if available. I am not sure off hand whether it
fell back to querying 'utmp' but the subject of bug #904 was the fact
that this core package now pulled in libsystemd0, making a
libsystemd0-free Devuan installation *impossible*.
Therefore the new experimental version of 'coreutils' does *not* link
with libsystemd0 and only shows the current sessions from /run/utmp.
The output from 'who' and 'users' will now match 'w' in Debian, showing
all and only the sessions recorded in /run/utmp, which now includes
virtual console logins (e.g. tty1) and ssh logins and maybe others but
it depends on the software that records them.
Epilogue: did any of this need to happen?
-----------------------------------------
I'm not sure when exactly this happened but glibc seems to have changed
the definition of struct utmp to have an unsigned seconds field. This
means that the whole OS could have been made 2160-safe instead of
scrapping all the existing methods. There's a case to be made that the
new methods should have been trialled in parallel with keeping the old
methods in place and making sure software worked properly with the new
unsigned seconds field.
Andrew