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

Re: utmp in trixie



[Responding to an old message]

On 4/1/25 22:27, Michael Stone 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 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?

There's one more prob with current setup in trixie: all
mentioned utilities (w/who/users/etc) require pam_systemd
and doesn't work without.

 $ ssh tsrv
 ...
 Last login: Wed Dec  3 09:23:36 2025 from 192.168.177.146
 mjt@tsrv:~$ w
  10:36:20 up 9 days,  9:08,  0 users,  load average: 1.02, 1.10, 1.09
 USER     TTY      FROM             LOGIN@   IDLE   JCPU   PCPU  WHAT
 mjt@tsrv:~$ who
 mjt@tsrv:~$ users
 mjt@tsrv:~$


/run/utmp[x] isn't created by default at all.  I can touch it, and it
will be used by at least sshd.  But it is still not useful:

 $ ssh tsrv
 ...
 Last login: Wed Dec  3 10:36:20 2025 from 192.168.177.146
 mjt@tsrv:~$ w
  10:37:53 up 9 days,  9:09,  1 user,  load average: 1.11, 1.10, 1.09
 USER     TTY      FROM             LOGIN@   IDLE   JCPU   PCPU  WHAT
 mjt@tsrv:~$ who
 mjt@tsrv:~$ users
 mjt@tsrv:~$

Note the number of logged-in users changed from 0 to 1 (this is
after creating an empty /run/utmpx).

Now,

 mjt@tsrv:~$ who /run/utmpx
 mjt      pts/2        2025-12-03 10:37 (192.168.177.146)


This is a record added by sshd.  I dunno which other software adds
utmp records.

By default (with no args), who(1) passes READ_UTMP_CHECK_PIDS flag
to readutmp(), and apparently, sshd adds a record with pid=0, so
readutmp() skips it, - hence by default, who doesn't list any users.

So basically, without pam-systemd, there's no w/who/users/etc at all.

Now, it looks like I should review the code in sshd and find out why
the utmp records it makes are being disliked by w/who.  Or it is
w/who who are wrong here, I dunno yet.  Either way, this feels wrong
somehow.


(One might ask why I can't install pam-systemd.  And this is a very
good question.  The prob is - these are long-running servers which
needs to be rebooted sometimes too, but they usually take long time
to reboot, and sometimes needs some portion of babysitting in there.
The only local users are administrators (doing the reboots too).
If I install pam-systemd, the first thing the system does right
after `systemctl reboot` is to terminate all user sessions, - which
is just one, the one doing the reboot.  So I can't watch the system
doing the work and help it in case of a problem.  I haven't found
any solution for that besides dropping pam-systemd - which makes
perfect fit).

Thanks,

/mjt


Reply to: