Unable to get w or who commands working after Debian 13 upgrade

Troubleshooting
1

Creating a bug report/issue

I have searched the existing open and closed issues

Required Information

  • DietPi version | cat /boot/dietpi/.version
    • G_DIETPI_VERSION_CORE=10
    • G_DIETPI_VERSION_SUB=5
    • G_DIETPI_VERSION_RC=2
    • G_GITBRANCH=‘master’
    • G_GITOWNER=‘MichaIng’
  • Distro version | echo $G_DISTRO_NAME $G_RASPBIAN
    • trixie 0
  • Kernel version | uname --all
    • Linux trixienow 6.18.39+rpt-rpi-v8 #1 SMP PREEMPT Debian 1:6.18.39-1+rpt1 (2026-07-29) aarch64 GNU/Linux
  • Architecture | dpkg --print-architecture
    • arm64
  • SBC model | echo $G_HW_MODEL_NAME or (EG: RPi3)
    • Raspberry Pi 4 Model B Rev 1.4
  • Power supply used | (EG: 5V 1A RAVpower)
    • Official Raspberry Pi 4 AC Adapter
  • SD card used | (EG: SanDisk ultra)
    • N/A as running only off USB hard drive

Additional Information (if applicable)

  • Software title | (EG: Nextcloud)
    • Upgraded from Debian 12 to Debian 13
  • Was the software title installed freshly or updated/migrated?
    • w and who were working before the upgrade
  • Can this issue be replicated on a fresh installation of DietPi?
    • I believe so
  • Bug report ID | echo $G_HW_UUID

Steps to reproduce

  1. Upgrade Dietpi running Debian 12 (bookworm) to Debian 13 (trixie) using the script located at Debian 13 Trixie has been released – DietPi Blog
  2. The above blog post mentions software to install to get the functionality back for w and who, but that does not work.
  3. I do find This Github issue mentioning how to get w and who working, but that does not work either.
  4. Unable to have functional w and who commands as in Debian 12 (bookworm).

Expected behaviour

  • w and who commands should function in Debian 13 (trixie) as they were in Debian 12 (bookworm).

Actual behaviour

  • w and who commands are not functional after upgrading to Debian 13 (trixie).

Extra details

  • N/A
paste lines of logs or code into such code fences here
2

See here below “1.3.2 lastlog and wtmp/utmp replacements”: Debian 13 Trixie has been released – DietPi Blog

3

I read that and installed everything recommended as follows:

sudo apt install lastlog2 libpam-lastlog2 wtmpdb libpam-wtmpdb dbus
sudo systemctl unmask systemd-logind
sudo systemctl start dbus systemd-logind

But I’m confused as to how to get w and who functional. Do I just have lastlog2 as their replacement?

4

Oh, for these two, systemd PAM integration is needed, which we missed in the blog post:

sudo apt install libpam-systemd

This also means, that logins via Dropbear SSH server are not tracked, since it has no full PAM integration.

lastlog2 and wtmpdb are both not needed for w and who.

5

Odd as that was already installed and neither w nor who are functioning as expected.

The output of who produces is nothing.

The output of w is :

$ w
 09:52:15 up 2 days, 17:26,  0 users,  load average: 0.33, 0.37, 0.35
USER     TTY      FROM             LOGIN@   IDLE   JCPU   PCPU  WHAT

Any ideas what to try next?

6

As of my note about Dropbear: Do you use OpenSSH as SSH server, or does it not work on local console (HDMI) logins either?

7

I use OpenSSH, so I was expecting it to now function. It is running headless, so have been unable to test on local console (HDMI) login yet.

8

Hmm. I just did this on a fresh DietPi system:

  1. Switch to OpenSSH server in dietpi-software
  2.  apt install libpam-systemd
 systemctl unmask systemd-logind
 systemctl start dbus systemd-logind
 exit
  3. Reconnect via SSH, then:
    root@VM-Trixie:~# w
 00:53:55 up 3 min,  1 user,  load average: 0.06, 0.10, 0.05
USER     TTY      FROM             LOGIN@   IDLE   JCPU   PCPU  WHAT
root     pts/0    192.168.1.3      00:53    1.00s  0.02s   ?    w
root@VM-Trixie:~# who
root     sshd pts/0   2026-08-07 00:53 (192.168.1.3)

If this really does not work in your case, verify that systemd-logind succeeded, and that you really connected through OpenSSH:

systemctl status systemd-logind
pgrep sshd-session
echo $PPID
9

I have followed the instructions you’ve provided and still having same issue in OP.

This system is not a fresh DietPi system, as it has been upgraded from Debian 11 → 12 → and now to 13. This functionality did work with the two previous Debian releases.

Here is what I get to verify that systemd-logind succeeded:

$ sudo systemctl status systemd-logind
● systemd-logind.service - User Login Management
     Loaded: loaded (/usr/lib/systemd/system/systemd-logind.service; static)
    Drop-In: /usr/lib/systemd/system/systemd-logind.service.d
             └─dbus.conf
     Active: active (running) since Mon 2026-08-03 16:25:34 EDT; 3 days ago
 Invocation: 072b2ceca5d44331b71845bb5f313dad
       Docs: man:sd-login(3)
             man:systemd-logind.service(8)
             man:logind.conf(5)
             man:org.freedesktop.login1(5)
   Main PID: 362 (systemd-logind)
     Status: "Processing requests..."
      Tasks: 1 (limit: 9394)
   FD Store: 2 (limit: 768)
     Memory: 2.1M (peak: 2.8M)
        CPU: 1.319s
     CGroup: /system.slice/systemd-logind.service
             └─362 /usr/lib/systemd/systemd-logind

Aug 03 22:00:09 trixienow systemd-logind[362]: Session c1 logged out. Waiting for processes to exit.
Aug 03 22:00:09 trixienow systemd-logind[362]: Removed session c1.
Aug 03 22:00:19 trixienow systemd-logind[362]: Removed session 1.
Aug 04 08:32:25 trixienow systemd-logind[362]: New session c2 of user root.
Aug 04 08:32:25 trixienow systemd-logind[362]: New session 22 of user root.
Aug 04 08:41:10 trixienow systemd-logind[362]: Session c2 logged out. Waiting for processes to exit.
Aug 04 08:41:10 trixienow systemd-logind[362]: Removed session c2.
Aug 04 08:41:20 trixienow systemd-logind[362]: Removed session 22.
Aug 06 22:37:03 trixienow systemd-logind[362]: New session c3 of user root.
Aug 06 22:37:04 trixienow systemd-logind[362]: New session 99 of user root.

$ pgrep sshd-session
22327
22329
22438
22440

$ echo $PPID
22329

When I SSH in, I still do not see the login with w, but if I sudo -i to the root user after login, then I do see that, as shown here:

$ w
 22:42:58 up 3 days,  6:17,  0 users,  load average: 0.51, 0.34, 0.24
USER     TTY      FROM             LOGIN@   IDLE   JCPU   PCPU  WHAT
$ w
 22:43:03 up 3 days,  6:17,  1 user,  load average: 0.47, 0.34, 0.24
USER     TTY      FROM             LOGIN@   IDLE   JCPU   PCPU  WHAT
root     pts/1    -                22:43    7.00s  0.11s  0.04s sudo -i

This is unexpected behavior, so any suggestions on what to try next are greatly appreciated.

10

I haven’t tested as non-root user yet. Let’s see:

dietpi@VM-Trixie:~$ w
 21:45:23 up 0 min,  1 user,  load average: 0.14, 0.03, 0.01
USER     TTY      FROM             LOGIN@   IDLE   JCPU   PCPU  WHAT
dietpi   pts/1    192.168.1.3      21:45    2.00s  0.06s  0.02s w
dietpi@VM-Trixie:~$ who
dietpi   sshd pts/1   2026-08-07 21:45 (192.168.1.3)

That dietpi user not in any additional groups either :thinking:. Can you show the full systemd-logind output?

dietpi@VM-Trixie:~$ sudo journalctl -u systemd-logind
Aug 07 21:45:04 VM-Trixie systemd[1]: Starting systemd-logind.service - User Login Management...
Aug 07 21:45:04 VM-Trixie systemd-logind[422]: New seat seat0.
Aug 07 21:45:04 VM-Trixie systemd-logind[422]: Watching system buttons on /dev/input/event3 (Power Button)
Aug 07 21:45:04 VM-Trixie systemd-logind[422]: Watching system buttons on /dev/input/event4 (Sleep Button)
Aug 07 21:45:04 VM-Trixie systemd-logind[422]: Watching system buttons on /dev/input/event0 (AT Translated Set 2 keyboard)
Aug 07 21:45:04 VM-Trixie systemd[1]: Started systemd-logind.service - User Login Management.
Aug 07 21:45:21 VM-Trixie systemd-logind[422]: New session 1 of user dietpi.
Aug 07 21:45:21 VM-Trixie systemd-logind[422]: New session 2 of user dietpi.

It shows the dietpi user session being recognized. In your case I see only a root user session. But there were two prior sessions 1 and c1, from before the truncated log. c1 and c2 are also interesting session IDs. I see only numeric IDs, no matter how I login (local console, SSH, sudo -i) and with which user. And they are strictly serially counting up.

Also the loginctl gives an overview. If that does not show any dietpi user session, we know it is no registered in the first place.

Is a session registered when you run sudo -i -u dietpi (resp. the non-root user you use) from within the non-root user session?

Also, as you said the system has been dist-upgraded two times, this is how to check differences between your SSH server config and the default one, if there are any:

diff /etc/ssh/sshd_config /etc/ssh/sshd_config.dpkg-dist
11

Full systemd-logindoutput is:

$ sudo journalctl -u systemd-logind
Aug 10 14:28:53 trixienow systemd[1]: Starting systemd-logind.service - User Login Management...
Aug 10 14:28:53 trixienow systemd-logind[354]: New seat seat0.
Aug 10 14:28:53 trixienow systemd[1]: Started systemd-logind.service - User Login Management.
$ who
$ w
 14:29:23 up 0 min,  0 users,  load average: 0.20, 0.05, 0.01
USER     TTY      FROM             LOGIN@   IDLE   JCPU   PCPU  WHAT

Running loginctl does not show any dietpi user session:

$ loginctl
SESSION UID USER SEAT LEADER CLASS TTY IDLE SINCE
No sessions.

Result after running sudo -i -u dietpi

$ who
dietpi   pts/0        2026-08-10 14:33
$ w
 14:33:14 up 4 min,  1 user,  load average: 0.85, 0.54, 0.22
USER     TTY      FROM             LOGIN@   IDLE   JCPU   PCPU  WHAT
dietpi   pts/0    -                14:33    1.00s  0.14s  0.03s sudo -i -u dietpi

I did not have a sshd_config.dpkg-dist file, but I had a different file there to diff against sshd_config

$ diff /etc/ssh/sshd_config /etc/ssh/sshd_config.ucf-dist 
1d0
< #	$OpenBSD: sshd_config,v 1.103 2018/04/09 20:41:22 tj Exp $
6c5
< # This sshd was compiled with PATH=/usr/bin:/bin:/usr/sbin:/sbin
---
> # This sshd was compiled with PATH=/usr/local/bin:/usr/bin:/bin:/usr/games
34c33
< PermitRootLogin no
---
> #PermitRootLogin prohibit-password
36c35
< MaxAuthTries 3
---
> #MaxAuthTries 6
57,63c56,64
< # To disable tunneled clear text passwords, change to no here!
< PasswordAuthentication no 
< PermitEmptyPasswords no
< 
< # Change to yes to enable challenge-response passwords (beware issues with
< # some PAM modules and threads)
< ChallengeResponseAuthentication no
---
> # To disable tunneled clear text passwords, change to "no" here!
> PasswordAuthentication no
> #PermitEmptyPasswords no
> 
> # Change to "yes" to enable keyboard-interactive authentication.  Depending on
> # the system's configuration, this may involve passwords, challenge-response,
> # one-time passwords or some combination of these and other methods.
> # Beware issues with some PAM modules and threads.
> KbdInteractiveAuthentication no
79c80
< # be allowed through the ChallengeResponseAuthentication and
---
> # be allowed through the KbdInteractiveAuthentication and
81,82c82,83
< # PAM authentication via ChallengeResponseAuthentication may bypass
< # the setting of "PermitRootLogin without-password".
---
> # PAM authentication via KbdInteractiveAuthentication may bypass
> # the setting of "PermitRootLogin prohibit-password".
85,86c86,87
< # and ChallengeResponseAuthentication to 'no'.
< UsePAM no
---
> # and KbdInteractiveAuthentication to 'no'.
> UsePAM yes
103c104
< #PidFile /var/run/sshd.pid
---
> #PidFile /run/sshd.pid
112,113c113,114
< # Allow client to pass locale environment variables
< AcceptEnv LANG LC_*
---
> # Allow client to pass locale and color environment variables
> AcceptEnv LANG LC_* COLORTERM NO_COLOR

My sshd_config file has not been changed since 2022, but I do notice one major difference here, which is UsePAM being different between them.

After changing UsePAM from no to yes, and restarting sshd, both w and who now work as expected. Thank you for helping me solve this issue.

12

The TL;DR solution to this issue

After changing UsePAM from no to yes, and restarting sshd, both w and who now work as expected. Thank you for helping me solve this issue.

13

Oh, that makes sense. PAM is enabled by default in OpenSSH, hence I wasn’t considering this being disabled.

Something else I recognized is that your config still contains the legacy ChallengeResponseAuthentication setting, while our Trixie upgrade script should have replaced this with KbdInteractiveAuthentication. Can you run the following (long :sweat_smile:) command and check whether it updates the setting?

[[ -f '/etc/ssh/sshd_config' ]] && grep -q '^[[:blank:]]*ChallengeResponseAuthentication[[:blank:]]' /etc/ssh/sshd_config && ! grep -q '^[[:blank:]]*KbdInteractiveAuthentication[[:blank:]]' /etc/ssh/sshd_config && G_EXEC sed --follow-symlinks -Ei 's/^([[:blank:]]*)ChallengeResponseAuthentication([[:blank:]])/\1KbdInteractiveAuthentication\2/' /etc/ssh/sshd_config

Seeing all the comments which reference it, I think we should do a more aggressive replacement anyway:

G_EXEC sed --follow-symlinks -i 's/ChallengeResponseAuthentication/KbdInteractiveAuthentication/' /etc/ssh/sshd_config
14

I can confirm that running that long command does update the setting. Thank you again.