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 seat0 2025-02-15 10:11 (login screen)
eggert tty2 2025-02-15 10:11 (tty2)
$ ./who-with-systemd # Configured with --enable-systemd.
eggert seat0 2025-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/3 2025-02-16 22:56 (47.147.225.25)
$ ./who-with-systemd
gdm seat0 2025-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.
