Hi, On Wed, 2 Apr 2025 at 06:27, Michael Stone <mst...@debian.org> wrote:
> /run/utmp is no longer provided in trixie, which means that the > mechanisms used to show active sessions in unix for several decades no > longer work. There's a replacement mechanism provided by systemd, but > it's not 1:1. I'm the procps maintainer for both upstream and Debian. procps provides some of these tools that used to, or still can, use utmp. The Debian package and upstream with the --with-systemd configure option will both use and prefer the information provided by systemd over utmp (if both happen) to be available.) As to it being not 1:1, that's partly correct, but the longer answer is, well longer. * There are things that have just gone missing and aren't related to utmp, such as idle time. * If you compile procps without systemd and run it on a host with no utmp, you see 0 users. * There is also the fact you might not see *term users. This is because for systemd they are the same session, so you see it once. The issue with utmp is there are no rules so say gnome-terminal you'd see the user but kterm you won't (or vice-versa, I forget who does what). That is because, in a way, the right answer is it's a single user. * There might be some remote users that get missed, basically not visible via sd_session_get_remote_host() but are in ut_addr_v6 in the utmp struct. I'm not sure how common this is or why/if it happens; i suspect it is some pam_session brokenness/corner case. > I propose that for trixie *both* mechanisms are active, so > a person can choose between them (and compare the output, to better > identify gaps between the historic utmp mechanism and the new and > improved systemd facility). I've been told that the reason this can't be > done is that utmp isn't y2038 compliant, but it seems to me that we > won't be supporting trixie in y2038, so who cares? Are there any factors > to consider that I've missed? > Yes, there is definitely a Y2038 issue, there are also issues with utmp not being handled consistently and some security issues around who can do what to the file. For me and procps utils in Debian, we don't use utmp and don't need it. Having utmp there won't change the tools' outputs. If the project at large says they want the file to hang around, that's ok by me but it won't give ps/w/etc any more details. - Craig
