Hi, Let me clarify some things.
On Sun, Feb 16, 2025 at 11:52 PM Paul Eggert <egg...@cs.ucla.edu> 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)
