[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: utmp in trixie



Hi,

On Wed, 2 Apr 2025 at 06:27, Michael Stone <mstone@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


Reply to: