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

From: Thorsten Kukuk <[email-masked]>
Date: Mon, 17 Feb 2025 08:03:23 +0100

Hi,

Let me clarify some things.

On Sun, Feb 16, 2025 at 11:52 PM Paul Eggert <[email-masked]> wrote:
>
> At this point I confess I don't know what changes would be needed for
> GNU 'who'. I see a difference of opinion as to whether 'w' works. There
> seem to be multiple mechanisms in play (utmp, wtmp, wtmpdb, lastlog2,
> logind, maybe others?) and I don't know when to use which, or even how
> to use them except for the traditional utmp/wtmp files.

Let's give a short summary:

lastlog from util-linux got replaced with lastlog2. There were very
few applications creating lastlog entries and using them to display
the last login message. This code can be removed, this is handled now
by pam_lastlog2.so, so that all applications have support for it. I'm
not aware of any utility outside of util-linux who reads the lastlog
file for different reasons.

wtmpdb replaces /var/log/wtmp. Applications, who just created wtmp
entries: this code can be disabled, we have now pam_wtmpdb.so to
create common, correct wtmp entries.
Applications who did read wtmp  files for whatever reasons need to be
adjusted to use wtmpdb. But again, this don't really exist. Majority
of applications only create the login/logout entries, which is now
handled by the PAM module. The other two cases were runlevel
management of SysVinit and entries for synchronizing the local clock.
runlevel entries are not used by systemd and there is no tool left
which creates entries to synchronize  the clock for at least two
decades.
If your application did not read wtmp entries in the past, there is
absolutely no reason to add wtmpdb support. Especially as wtmpdb is
not a replacement for utmp.

utmp: utmp got replaced by systemd-logind. Code which creates utmp
entries can be removed, this is now handled by systemd-logind.
Applications reading utmp need to be adjusted to use libsystemd. There
is no file based access for utmp anymore (ok, not fully correct,
systemd-logind stores the data on disk) and lastlog2 and wtmpdb are no
file based replacements for utmp as what was wrongly claimed in one of
the bug reports. So if your application was using utmp, it needs to
use systemd-logind today and not lastlog2 or wtmpdb.

Now to the bug reports, there are two different things:

1. Looks like w is compiled with libsystemd support, who is not.
Compiling who with libsystemd support should already solve most of the
problems as Chris Hofstaedtler already wrote.
2. fake utmp entries created by terminal applications don't work anymore.

Some terminal applications (e.g. xterm, konsole, ...) create fake utmp
entries for historic reasons: so that broadcast messages are shown in
every single terminal. Which for people, who only work with graphical
applications, but not terminals, is not from help, as they will never
see them.
This is for most users very annoying, that's why the other half does
not create such entries. GNOME e.g. did never create such fake utmp
entries, the claims of some people in that bug reports are wrong. Even
worse: the utmp entries created by GNOME are partly broken, that's why
wall does not work on most GNOME systems which use utmp and not
systemd-logind at all.

The fake utmp entries are no longer created with systemd-logind. For
the majority of people in the discussions and at conferences this was
a plus. KDE e.g. has a daemon, which listens to wall messages and
shows them exactly once in one window. So that even people not using a
terminal get them. But to be honest, I don't know what the state here
is. But at least on openSUSE nobody noticed that the fake utmp entries
are gone, and the majority of who noticed is happy that they are gone.

Future: glibc 2.42 will remove support for utmp and wtmp according to
the current plans. This is the only remaining open issue in openSUSE
with the switch away from utmp and wtmp. Latest with this all
applications should use systemd-logind and wtmpdb as replacement.

> Perhaps whoever has changed the longstanding API (is that Thorsten
> Kukuk, or someone else? anyway I'll cc Thorsten) can chime in with a
> proposed patch to bleeding-edge GNU coreutils. This would probably mean
> a patch to Gnulib's readutmp module, which already is supposed to work
> with systemd's new utmp interfaces but I guess some people are reporting
> problems with it? (This is unclear.)
>
> For what it's worth, I briefly looked at
> <https://build.opensuse.org/package/show/openSUSE%3AFactory/coreutils>
> and didn't see a patch there.  So perhaps the problem is already
> addressed in bleeding-edge Coreutils?

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. Having a mix of
applications using utmp or systemd-logind is not helpful, they all
need to use the same backend.

> Without some actionable advice from experts in this area, I don't see
> this portability issue being fixed any time soon.
>
> For now, I've merged the following GNU Coreutils bug reports as they all
> seem to be the same topic.
>
> https://bugs.gnu.org/73928
> https://bugs.gnu.org/76346
> https://bugs.gnu.org/76347

Yes, see above, all are based on the same two problems.

I hope this helped,
Thoresten

-- 
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)