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