Re: bug#73928: Bug#1080330: coreutils: who no longer works

[Bruno Haible via Gnulib discussion list]

Chris Hofstaedtler wrote:
> I don't really know my way around the sd-logind API, but it looks
> like filtering on the session class (returned by sd_session_get_class)
> might be fruitful.
> 
> pam_systemd(8) has an explanation on the classes.

Thanks for the hint. Let me try this commit to gnulib. Paul, does it
work for you (after installing package 'systemd-devel' and rebuilding
coreutils with --enable-systemd)?


2025-02-19  Bruno Haible  

readutmp: Let callers distinguish LOGINs from USERs.
Reported by Paul Eggert in
.
* lib/readutmp.h (LOGIN_PROCESS, UT_TYPE_LOGIN_PROCESS): New macros.
* lib/readutmp.c (read_utmp_from_systemd): Possibly use LOGIN_PROCESS
instead of USER_PROCESS, depending on the session's class.

diff --git a/lib/readutmp.c b/lib/readutmp.c
index c5b6b3655b..9366dfa5c2 100644
--- a/lib/readutmp.c
+++ b/lib/readutmp.c
@@ -877,8 +877,8 @@ read_utmp_from_systemd (idx_t *n_entries, STRUCT_UTMP 
**utmp_buf, int options)
 }
 }
 
-  /* Create up to two USER_PROCESS entries: one for the seat,
- one for the tty.  */
+  /* Create up to two USER_PROCESS or LOGIN_PROCESS entries:
+ one for the seat, one for the tty.  */
   if (seat != NULL || tty != NULL)
 {
   char *user;
@@ -889,6 +889,13 @@ read_utmp_from_systemd (idx_t *n_entries, STRUCT_UTMP 
**utmp_buf, int options)
   if (sd_session_get_leader (session, &leader_pid) < 0)
 leader_pid = 0;
 
+  char *clasz;
+  if (sd_session_get_class (session, &clasz) < 0)
+clasz = missing;
+  short ctype =
+(strncmp (clasz, "manager", 7) == 0 ? LOGIN_PROCESS :
+ USER_PROCESS);
+
   char *host;
   char *remote_host;
   if (sd_session_get_remote_host (session, &remote_host) < 0)
@@ -932,7 +939,7 @@ read_utmp_from_systemd (idx_t *n_entries, STRUCT_UTMP 
**utmp_buf, int options)
   seat, strlen (seat),
   host, strlen (host),
   leader_pid /* the best we have */,
-  USER_PROCESS, start_ts, leader_pid, 0, 0);
+  ctype, start_ts, leader_pid, 0, 0);
   if (tty != NULL)
 a = add_utmp (a, options,
   user, strlen (user),
@@ -940,10 +947,12 @@ read_utmp_from_systemd (idx_t *n_entries, STRUCT_UTMP 
**utmp_buf, int options)
   tty, strlen (tty),
   host, strlen (host),
   leader_pid /* the best we have */,
-  USER_PROCESS, start_ts, leader_pid, 0, 0);
+  ctype, start_ts, leader_pid, 0, 0);
 
   if (host != missing)
 free (host);
+  if (clasz != missing)
+free (clasz);
   if (user != missing)
 free (user);
 }
diff --git a/lib/readutmp.h b/lib/readutmp.h
index b5e8133c7c..60d63df959 100644
--- a/lib/readutmp.h
+++ b/lib/readutmp.h
@@ -45,7 +45,7 @@
 # include 
 #endif
 
-/* Needed for BOOT_TIME and USER_PROCESS.  */
+/* Needed for BOOT_TIME, USER_PROCESS, LOGIN_PROCESS.  */
 #if HAVE_UTMPX_H
 # if defined _THREAD_SAFE && defined UTMP_DATA_INIT
 /* When including both utmp.h and utmpx.h on AIX 4.3, with _THREAD_SAFE
@@ -74,7 +74,8 @@ struct gl_utmp
   struct timespec ut_ts;/* time */
   pid_t ut_pid; /* process ID of ? */
   pid_t ut_session; /* process ID of session leader */
-  short ut_type;/* BOOT_TIME, USER_PROCESS, or other */
+  short ut_type;/* BOOT_TIME, USER_PROCESS, LOGIN_PROCESS,
+   or other */
   struct { int e_termination; int e_exit; } ut_exit;
 };
 
@@ -257,19 +258,21 @@ struct utmpx32
 # define WTMP_FILE "/etc/wtmp"
 #endif
 
-/* In early versions of Android,  did not define BOOT_TIME, only
-   USER_PROCESS.  We need to use the value that is defined in newer versions
-   of Android.  */
+/* In early versions of Android,  did not define BOOT_TIME or
+   LOGIN_PROCESS, only USER_PROCESS.  We need to use the value that is defined
+   in newer versions of Android.  */
 #if defined __ANDROID__ && !defined BOOT_TIME
 # define BOOT_TIME 2
+# define LOGIN_PROCESS 6
 #endif
 
 /* Some platforms, such as OpenBSD, don't have an ut_type field and don't have
-   the BOOT_TIME and USER_PROCESS macros.  But we want to support them in
-   'struct gl_utmp'.  */
+   the BOOT_TIME, USER_PROCESS, and LOGIN_PROCESS macros.  But we wa

Re: bug#73928: Bug#1080330: coreutils: who no longer works

[Chris Hofstaedtler]

* Paul Eggert  [250219 21:47]:
> On 2/19/25 09:41, Arsen Arsenović wrote:
> > they (gdm) are a user and they have a session.
> > Adding additional filtration can only confuse admins who compare 'who'
> > and other tools.
> 
> It is exactly that confusion that I'm trying to prevent.
> 
> The man page for "who" says "who - show who is logged on", but gdm is not
> logged on.
> 
> The POSIX spec for "who" says that "who" optionally reports the login time,
> but there is no login time here because nobody has logged in. The POSIX spec
> also says that "who -l" should list only lines where the system is waiting
> for someone to login - which is what's happening with the gdm display - and
> yet who with libsystemd doesn't do that.
> 
> It's a stretch to say that gdm is a "user" in the sense that most people
> understand "who". By default, "who" is supposed to list users who have
> logged in, not random UIDs like daemon or systemd-resolve or gdm that cannot
> log in.

I don't really know my way around the sd-logind API, but it looks
like filtering on the session class (returned by sd_session_get_class)
might be fruitful.

pam_systemd(8) has an explanation on the classes.

I would probably filter out these: greeter, lock-screen, manager,
manager-early. Looking at the "pam_issue" implementation, it only
counts sessions with a class matching user* as logged in users.

Chris

Re: bug#73928: Bug#1080330: coreutils: who no longer works

[Chris Hofstaedtler]

* Chris Hofstaedtler  [250219 22:41]:
> > The man page for "who" says "who - show who is logged on", but gdm is not
> > logged on.
[..]
> I don't really know my way around the sd-logind API, but it looks
> like filtering on the session class (returned by sd_session_get_class)
> might be fruitful.

This procps commit appears relevant:

https://github.com/warmchang/procps/commit/734930e4766860b7e57f0a3ae7d7f908f5d56153

Chris

Re: bug#73928: Bug#1080330: coreutils: who no longer works

[Paul Eggert]

On 2/19/25 09:41, Arsen Arsenović wrote:

they (gdm) are a user and they have a session.
Adding additional filtration can only confuse admins who compare 'who'
and other tools.


It is exactly that confusion that I'm trying to prevent.

The man page for "who" says "who - show who is logged on", but gdm is 
not logged on.


The POSIX spec for "who" says that "who" optionally reports the login 
time, but there is no login time here because nobody has logged in. The 
POSIX spec also says that "who -l" should list only lines where the 
system is waiting for someone to login - which is what's happening with 
the gdm display - and yet who with libsystemd doesn't do that.


It's a stretch to say that gdm is a "user" in the sense that most people 
understand "who". By default, "who" is supposed to list users who have 
logged in, not random UIDs like daemon or systemd-resolve or gdm that 
cannot log in.

Re: bug#73928: Bug#1080330: coreutils: who no longer works

[Arsen Arsenović]

Paul Eggert  writes:

> On 2025-02-19 03:26, Arsen Arsenović wrote:
>> The case for or against there being a user called 'gdm' when one
>> installs a Fedora system is one best presented to the Fedora hackers
>
> It's not just Fedora, it's also Ubuntu. Both systems have pseudousers named
> "gdm" that cannot log in (their login shell is /bin/false or /sbin/nologin),
> but which "who" would report with systemd. I assume other distros have similar
> problem.
>
> A simple fix is for "who" to silently filter out anybody named "gdm". (Sorry,
> Giovanni.)
>
> Is there a better way to distinguish real logins from fake ones?

I see these as real: they (gdm) are a user and they have a session.
Adding additional filtration can only confuse admins who compare 'who'
and other tools.
-- 
Arsen Arsenović


signature.asc
Description: PGP signature

Re: bug#73928: Bug#1080330: coreutils: who no longer works

[Paul Eggert]

On 2025-02-19 03:26, Arsen Arsenović wrote:

The case for or against there being a user called 'gdm' when one
installs a Fedora system is one best presented to the Fedora hackers


It's not just Fedora, it's also Ubuntu. Both systems have pseudousers 
named "gdm" that cannot log in (their login shell is /bin/false or 
/sbin/nologin), but which "who" would report with systemd. I assume 
other distros have similar problem.


A simple fix is for "who" to silently filter out anybody named "gdm". 
(Sorry, Giovanni.)


Is there a better way to distinguish real logins from fake ones?

Re: bug#73928: Bug#1080330: coreutils: who no longer works

[Bruno Haible via Gnulib discussion list]

Arsen Arsenović wrote:
> Sure, but one cannot name two users on a Unix system 'gdm', and there is
> a passwd entry for 'gdm', so that scenario is impossible (save for
> administrative errors):
> 
>   arsen@fedora:~$ grep gdm /etc/passwd
>   gdm:x:42:42:GNOME Display Manager:/var/lib/gdm:/usr/sbin/nologin
>   arsen@fedora:~$ useradd gdm
>   useradd: user 'gdm' already exists
> 
> Presumably Giovanni might pick 'giovannidm' or 'gdmicheli' or such
> instead.

OK. I withdraw my assessment that who's output was misleading. Paul,
do you still have a problem with this?

   $ ./who-with-systemd
   gdm  seat02025-02-13 18:04
   gdm  tty1 2025-02-13 18:04
   eggert   sshd pts/3   2025-02-16 22:56 (47.147.225.25)

Bruno

Re: bug#73928: Bug#1080330: coreutils: who no longer works

[Arsen Arsenović]

Bruno Haible  writes:

> Arsen Arsenović wrote:
>> This is correct, though, there is a session for the user 'gdm', and
>> they're taking up tty1.  If you walk up to that computer (you said you
>> were using SSH, so I assume you're remote), you'll see GDM running on
>> the screen (on one of the virtual TTYs).
>
> If Giovanni De Micheli has an account on this computer, who's output
> is ambiguous: you cannot tell whether the real user 'gdm' or the GNOME
> display manager is occupying the "seat". I would suggest that, at least,
> the GNOME display manager identifies itself as "(gdm)" instead of "gdm".

Sure, but one cannot name two users on a Unix system 'gdm', and there is
a passwd entry for 'gdm', so that scenario is impossible (save for
administrative errors):

  arsen@fedora:~$ grep gdm /etc/passwd
  gdm:x:42:42:GNOME Display Manager:/var/lib/gdm:/usr/sbin/nologin
  arsen@fedora:~$ useradd gdm
  useradd: user 'gdm' already exists

Presumably Giovanni might pick 'giovannidm' or 'gdmicheli' or such
instead.

The case for or against there being a user called 'gdm' when one
installs a Fedora system is one best presented to the Fedora hackers,
though, as it does not impact the correctness of the result above.
-- 
Arsen Arsenović


signature.asc
Description: PGP signature

Re: bug#73928: Bug#1080330: coreutils: who no longer works

[Arsen Arsenović]

Paul Eggert  writes:

>> 'who' merely reports the info it got from systemd-logind, and systemd-logind
>> most probably got a notification from gdm.
>> I agree with you that this _looks_like_ as if a user named 'gdm' was logged
>> in, and thus is misleading. But I don't think this should be fixed in
>> coreutils. Rather, this is something to work out between systemd-logind
>> and gdm.
>
> OK, but until that's worked out it appears to be better to not use
> --enable-systemd on Fedora when configuring Coreutils. Likewise for Ubuntu
> which has the same issue, and I assume Debian is like Ubuntu.

This is correct, though, there is a session for the user 'gdm', and
they're taking up tty1.  If you walk up to that computer (you said you
were using SSH, so I assume you're remote), you'll see GDM running on
the screen (on one of the virtual TTYs).
-- 
Arsen Arsenović


signature.asc
Description: PGP signature

Re: bug#73928: Bug#1080330: coreutils: who no longer works

[Bruno Haible via Gnulib discussion list]

Arsen Arsenović wrote:
> >> I agree with you that this _looks_like_ as if a user named 'gdm' was logged
> >> in, and thus is misleading. But I don't think this should be fixed in
> >> coreutils. Rather, this is something to work out between systemd-logind
> >> and gdm.
> >
> > OK, but until that's worked out it appears to be better to not use
> > --enable-systemd on Fedora when configuring Coreutils. Likewise for Ubuntu
> > which has the same issue, and I assume Debian is like Ubuntu.
> 
> This is correct, though, there is a session for the user 'gdm', and
> they're taking up tty1.  If you walk up to that computer (you said you
> were using SSH, so I assume you're remote), you'll see GDM running on
> the screen (on one of the virtual TTYs).

If Giovanni De Micheli has an account on this computer, who's output
is ambiguous: you cannot tell whether the real user 'gdm' or the GNOME
display manager is occupying the "seat". I would suggest that, at least,
the GNOME display manager identifies itself as "(gdm)" instead of "gdm".

Bruno

Re: bug#73928: Bug#1080330: coreutils: who no longer works

[Paul Eggert]

On 2025-02-17 00:22, Thorsten Kukuk wrote:

Maybe that systemd version is too old on that systems?


The systemd versions are reasonably recent. Fedora 41 has systemd 256.11 
(2025-01-08) and Ubuntu 24.10 has systemd 256.5 (2024-08-31). Here are 
the details:


On Fedora 41, "systemctl --version" reports:

systemd 256 (256.11-1.fc41)
+PAM +AUDIT +SELINUX -APPARMOR +IMA +SMACK +SECCOMP -GCRYPT +GNUTLS 
+OPENSSL +ACL +BLKID +CURL +ELFUTILS +FIDO2 +IDN2 -IDN -IPTC +KMOD 
+LIBCRYPTSETUP +LIBCRYPTSETUP_PLUGINS +LIBFDISK +PCRE2 +PWQUALITY 
+P11KIT +QRENCODE +TPM2 +BZIP2 +LZ4 +XZ +ZLIB +ZSTD +BPF_FRAMEWORK 
+XKBCOMMON +UTMP +SYSVINIT +LIBARCHIVE


On Ubuntu 24.10, the same command reports:

systemd 256 (256.5-2ubuntu3.1)
+PAM +AUDIT +SELINUX +APPARMOR +IMA +SMACK +SECCOMP +GCRYPT -GNUTLS 
+OPENSSL +ACL +BLKID +CURL +ELFUTILS +FIDO2 +IDN2 -IDN +IPTC +KMOD 
+LIBCRYPTSETUP +LIBCRYPTSETUP_PLUGINS +LIBFDISK +PCRE2 +PWQUALITY 
+P11KIT +QRENCODE +TPM2 +BZIP2 +LZ4 +XZ +ZLIB +ZSTD +BPF_FRAMEWORK 
-XKBCOMMON +UTMP +SYSVINIT +LIBARCHIVE





systemd  only writes the boot time, nothing else.


Is it that simple? systemd/src/core/exec-invoke.c's exec_invoke seems to 
do more than that if ENABLE_UTMP is defined.


Even if it's that simple, something is updating the traditional 
/var/run/utmp and /var/log/wtmp files on Fedora and Ubuntu and at least 
in some cases they work better than systemd does and this should be 
fixed somehow.

Re: bug#73928: Bug#1080330: coreutils: who no longer works

[Thorsten Kukuk]

On Mon, Feb 17, 2025 at 10:08 AM Paul Eggert  wrote:

> Even if it's that simple, something is updating the traditional
> /var/run/utmp and /var/log/wtmp files on Fedora and Ubuntu and at least
> in some cases they work better than systemd does and this should be
> fixed somehow.

Applications are doing that via glibc. But this will go away with
glibc 2.42, when this functions don't do anything anymore.
And this will not happen if distributions don't create /run/utmp on
boot. glibc only writes to this files if they exist, it will not
create them.

Thorsten

-- 
Thorsten Kukuk, Distinguished Engineer, Senior Architect, Future Technologies
SUSE Software Solutions Germany GmbH, Frankenstraße 146, 90461
Nuernberg, Germany
Managing Director: Ivo Totev, Andrew McDonald, Werner Knoblich (HRB
36809, AG Nürnberg)

Re: bug#73928: Bug#1080330: coreutils: who no longer works

[Paul Eggert]

On 2025-02-17 00:12, Bruno Haible wrote:

Paul Eggert wrote:

$ ./who-no-systemd # Configured normally.
eggert   seat02025-02-15 10:11 (login screen)
eggert   tty2 2025-02-15 10:11 (tty2)
$ ./who-with-systemd # Configured with --enable-systemd.
eggert   seat02025-02-15 10:11
eggert   tty2 2025-02-15 10:11

Apparently for coreutils, /var/run/utmp (the traditional interface) has
more info than libsystemd's API.


Both outputs are equivalent; the second one is less redundant.


In that case, should we fix Gnulib and/or Coreutils so that the first 
output is changed to match the second one?




$ ./who-no-systemd
eggert   pts/32025-02-16 22:56 (47.147.225.25)
$ ./who-with-systemd
gdm  seat02025-02-13 18:04
gdm  tty1 2025-02-13 18:04
eggert   sshd pts/3   2025-02-16 22:56 (47.147.225.25)

Here, though I'm logged in only via ssh, the libsystemd-using 'who'
incorrectly reports that a user named "gdm" is logged in in person.


'who' merely reports the info it got from systemd-logind, and systemd-logind
most probably got a notification from gdm.

I agree with you that this _looks_like_ as if a user named 'gdm' was logged
in, and thus is misleading. But I don't think this should be fixed in
coreutils. Rather, this is something to work out between systemd-logind
and gdm.


OK, but until that's worked out it appears to be better to not use 
--enable-systemd on Fedora when configuring Coreutils. Likewise for 
Ubuntu which has the same issue, and I assume Debian is like Ubuntu.

Re: bug#73928: Bug#1080330: coreutils: who no longer works

[Thorsten Kukuk]

On Mon, Feb 17, 2025 at 8:40 AM Paul Eggert  wrote:
>
> On 2025-02-16 23:03, Thorsten Kukuk wrote:
> > The problems were already all solved with the first coreutils versions
> > having systemd-logind support.  Even with all the bug reports I don't
> > see a need for changes in Coreutils, only in distributions not
> > enabling systemd-logind support in all packages.
>
> Thanks for the summary. Unfortunately I'm not seeing all the problems
> solved, at least not on current Fedora (41) and Ubuntu (24.10).
>
> If I configure current (f2e323430193956709aacca33f6b4fcab4fb9d8b)
> Coreutils with --enable-systemd on my Ubuntu 24.10 desktop, the output
> gets worse:
>
>$ ./who-no-systemd # Configured normally.
>eggert   seat02025-02-15 10:11 (login screen)
>eggert   tty2 2025-02-15 10:11 (tty2)
>$ ./who-with-systemd # Configured with --enable-systemd.
>eggert   seat02025-02-15 10:11
>eggert   tty2 2025-02-15 10:11
>
> Apparently for coreutils, /var/run/utmp (the traditional interface) has
> more info than libsystemd's API. (For what it's worth, both versions of
> "who" consult /var/run/utmp on Ubuntu 24.10, but the systemd version
> also consults /run/systemd/sessions/*.)

systemd-logind provides the same info as utmp does, I made sure that
this is the case and available:
https://github.com/thkukuk/utmpx/blob/main/utmp-to-logind.md

And who (with --enable-systemd with no /run/utmp on openSUSE Tumbleweed):
On a server:
kukukpts/32025-02-12 11:20 (192.168.122.1)
kukukpts/02025-02-11 12:00 (192.168.122.1)
kukukpts/12025-02-11 14:26 (192.168.122.1)

On my local machine with KDE:
kukukseat02025-02-11 15:58 (:0)
kukuktty2 2025-02-11 15:58 (:0)
root pts/22025-02-15 18:32

No idea why this is not working for you. On openSUSE we have no
additional patches which are not upstream.
Maybe that systemd version is too old on that systems?

> Similarly, on a Fedora 41 desktop where I'm not currently logged in, I
> get inferior results when Coreutils is configured with --enable-systemd:
>
>$ ./who-no-systemd
>eggert   pts/32025-02-16 22:56 (47.147.225.25)
>$ ./who-with-systemd
>gdm  seat02025-02-13 18:04
>gdm  tty1 2025-02-13 18:04
>eggert   sshd pts/3   2025-02-16 22:56 (47.147.225.25)
>
> Here, though I'm logged in only via ssh, the libsystemd-using 'who'
> incorrectly reports that a user named "gdm" is logged in in person.
>
> My guess is that, once systemd was changed to continue to output via the
> traditional /var/run/utmp and /var/log/wtmp files, people stopped
> configuring coreutils with --enable-systemd and stopped worrying about
> making sure that the more-modern systemd API works, which means that the
> traditional files are still essential.

systemd  only writes the boot time, nothing else.

Thorsten
-- 
Thorsten Kukuk, Distinguished Engineer, Senior Architect, Future Technologies
SUSE Software Solutions Germany GmbH, Frankenstraße 146, 90461
Nuernberg, Germany
Managing Director: Ivo Totev, Andrew McDonald, Werner Knoblich (HRB
36809, AG Nürnberg)

Re: bug#73928: Bug#1080330: coreutils: who no longer works

[Bruno Haible via Gnulib discussion list]

Paul Eggert wrote:
> If I configure current (f2e323430193956709aacca33f6b4fcab4fb9d8b) 
> Coreutils with --enable-systemd on my Ubuntu 24.10 desktop, the output 
> gets worse:
> 
>$ ./who-no-systemd # Configured normally.
>eggert   seat02025-02-15 10:11 (login screen)
>eggert   tty2 2025-02-15 10:11 (tty2)
>$ ./who-with-systemd # Configured with --enable-systemd.
>eggert   seat02025-02-15 10:11
>eggert   tty2 2025-02-15 10:11
> 
> Apparently for coreutils, /var/run/utmp (the traditional interface) has 
> more info than libsystemd's API.

Both outputs are equivalent; the second one is less redundant.
  - The comment "(tty2)" is redundant because it's already the tty.
  - The comment "(login screen)" is redundant because that's the
concept of a "seat".

> Similarly, on a Fedora 41 desktop where I'm not currently logged in, I 
> get inferior results when Coreutils is configured with --enable-systemd:
> 
>$ ./who-no-systemd
>eggert   pts/32025-02-16 22:56 (47.147.225.25)
>$ ./who-with-systemd
>gdm  seat02025-02-13 18:04
>gdm  tty1 2025-02-13 18:04
>eggert   sshd pts/3   2025-02-16 22:56 (47.147.225.25)
> 
> Here, though I'm logged in only via ssh, the libsystemd-using 'who' 
> incorrectly reports that a user named "gdm" is logged in in person.

'who' merely reports the info it got from systemd-logind, and systemd-logind
most probably got a notification from gdm.

I agree with you that this _looks_like_ as if a user named 'gdm' was logged
in, and thus is misleading. But I don't think this should be fixed in
coreutils. Rather, this is something to work out between systemd-logind
and gdm.

Bruno

Re: bug#73928: Bug#1080330: coreutils: who no longer works

[Paul Eggert]

On 2025-02-16 23:03, Thorsten Kukuk wrote:

The problems were already all solved with the first coreutils versions
having systemd-logind support.  Even with all the bug reports I don't
see a need for changes in Coreutils, only in distributions not
enabling systemd-logind support in all packages.


Thanks for the summary. Unfortunately I'm not seeing all the problems 
solved, at least not on current Fedora (41) and Ubuntu (24.10).


If I configure current (f2e323430193956709aacca33f6b4fcab4fb9d8b) 
Coreutils with --enable-systemd on my Ubuntu 24.10 desktop, the output 
gets worse:


  $ ./who-no-systemd # Configured normally.
  eggert   seat02025-02-15 10:11 (login screen)
  eggert   tty2 2025-02-15 10:11 (tty2)
  $ ./who-with-systemd # Configured with --enable-systemd.
  eggert   seat02025-02-15 10:11
  eggert   tty2 2025-02-15 10:11

Apparently for coreutils, /var/run/utmp (the traditional interface) has 
more info than libsystemd's API. (For what it's worth, both versions of 
"who" consult /var/run/utmp on Ubuntu 24.10, but the systemd version 
also consults /run/systemd/sessions/*.)


Similarly, on a Fedora 41 desktop where I'm not currently logged in, I 
get inferior results when Coreutils is configured with --enable-systemd:


  $ ./who-no-systemd
  eggert   pts/32025-02-16 22:56 (47.147.225.25)
  $ ./who-with-systemd
  gdm  seat02025-02-13 18:04
  gdm  tty1 2025-02-13 18:04
  eggert   sshd pts/3   2025-02-16 22:56 (47.147.225.25)

Here, though I'm logged in only via ssh, the libsystemd-using 'who' 
incorrectly reports that a user named "gdm" is logged in in person.


My guess is that, once systemd was changed to continue to output via the 
traditional /var/run/utmp and /var/log/wtmp files, people stopped 
configuring coreutils with --enable-systemd and stopped worrying about 
making sure that the more-modern systemd API works, which means that the 
traditional files are still essential.


I'll add bug-gnulib to the cc list as this may be a Gnulib issue.