Fedora recently added systemd-devel to the build dependencies for coreutils: - https://src.fedoraproject.org/rpms/coreutils/c/d3137f0cd04f6c716ef7c64ae35aa653e22aefea?branch=f41
This had the side-effect of the ./configure script defining READUTMP_USE_SYSTEMD, enabling read_utmp_from_systemd() in lib/readutmp.c: - http://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=blob;f=lib/readutmp.c;h=10d79d1d81a5eeb9da7cbfcc72f214430abcfa2c;hb=HEAD#l800 This impacts the output of the "who" command when someone is logged in via Cockpit. The old version printed: admin web console 2024-08-26 08:46 (::ffff:172.27.0.2) and the new version simply doesn't list the login. The readutmp code generally only lists a session if it either has a tty defined or if it has an associated seat. Not all login session are like that. Consider a command run over ssh without allocating a terminal. In that case though, there is a heuristic (search "Try harder" in the code) that gets enabled if the session type (as returned by sd_session_get_type()) is set to "tty" (which it is for ssh, even if there is no actual pseudoterminal device). That heuristic results in the name of the service being written in place of the tty device. Cockpit sets its session type to "web" and therefore doesn't get the same treatment. "web" is a supported session type in systemd-logind since ~10 years, although it was never documented. See https://github.com/systemd/systemd/pull/34128 about that. So I guess my wish here is open-ended, but something like "please allow for a way to ensure that web logins appear in the output of who" without requiring us to set our session type to "tty" (which we don't want to do). This could look like adding a special case for "web" session types but probably a more permissive approach for listing the service name for all sessions without a tty might make sense? We're also open to setting other session attributes as may be appropriate. In the utmp case we have some rather old code for writing "web console" as "tty" field, but I'd like to avoid that on the new code path... Thanks for your consideration. Allison Karlitskaya
