So, while operating on an Ubuntu 25.10 I had to use who to check the session, and something weird happened it basically didn't work, for a simple command not to work, I knew something was up with my machine so I did some digging, turns out the next alternative "w" was working just fine but not who. My curiosity rose I checked out Launchpad Bug #2130814, other people encountered it as well and everyone had a different theory why the "who" not work but "w" did. So what happens is if you run "who" it would just return Exit Code: 0 and will not show you any information.
The bug
$ who
$ echo $?
0
While tracking down the reason for this behavior, I got a lot of information that I was not really aware of, the real reason is Ubuntu is moving away from a mechanism that has been working for them since 1970s. While suspected its not a uutils-vs-gnu issue either, cause kind of the same thing happens with gnuwho
$ gnuwho
$ echo $?
0
Both broken
So, while looking at the bug https://bugs.launchpad.net/ubuntu/+source/coreutils/+bug/2130814 which is open for a while, the original reporter noticed /var/run/utmp is missing, another possible reason seen by a reporter was an EACCESS (Permission Denied) on the /run/systemd/sessions/3 so probably AppArmor was denying it.
I started by checking whether session tracking itself was broken. It wasn't.
$ loginctl list-sessions
SESSION UID USER SEAT LEADER CLASS TTY IDLE SINCE
4 1000 ubuntu - 1010 user - no -
5 1000 ubuntu - 1313 manager - no -
2 sessions listed.
Session do exist. Systemd knows it, for some reason who wasn't reading it. Next I checked the AppArmor theory, the other commentator saw "EACCESS" but on a clean Ubuntu 25.10 the session files had the required readable permission
$ ls -la /run/systemd/sessions/
-rw-r--r-- 1 root root 330 Apr 26 18:27 4
-rw-r--r-- 1 root root 309 Apr 26 18:27 5
So files were present their and world-readable, "who" just doesn't look at it. The output of loginctl --version made things click:
$ loginctl --version
systemd 257 (257.9-0ubuntu2.4)
+PAM +AUDIT +SELINUX +APPARMOR +IMA +IPE +SMACK +SECCOMP +GCRYPT
-GNUTLS +OPENSSL +ACL +BLKID +CURL +ELFUTILS +FIDO2 +IDN2 -IDN +IPTC
+KMOD +LIBCRYPTSETUP +LIBCRYPTSETUP_PLUGINS +LIBFDISK +PCRE2 +PWQUALITY
+P11KIT +QRENCODE +TPM2 +BZIP2 +LZ4 +XZ +ZLIB +ZSTD +BPF_FRAMEWORK +BTF
-XKBCOMMON -UTMP +SYSVINIT +LIBARCHIVE
Look near the end: -UTMP.
Each of the flag shows whether systemd was built with that feature. A '+' means included a '-' means excluded. Most of them are included except UTMP.
UTMP is Unix mechanism for tracking the logged in users. The files that are used by UTMP are /var/run/utmp and /var/run/utmpx and tools like 'who', 'last' and 'w' uses this. The modern Ubuntu 25.10 is made without this
$ ls -la /var/run/utmp /var/run/utmpx
ls: cannot access '/var/run/utmp': No such file or directory
ls: cannot access '/var/run/utmpx': No such file or directory
But why
In October 2024, Debian systemd maitainer announced that the support for UMTP will be discontinued. The reason was y2038 problem, to elaborate, UTMP works on a 32 bit system, due to limited bits it would overflow on January 19 2038, so rather than redesigning the whole system the world is pivoting to wtmpdb as the successor. wtmpdb is a SQLite-backed login database to be y2038 safe. And if that doesn't work for you, you can use w. But this means while updating to new operating system or environment people might need to tweak some commands as well.
Why does w work though
$ w
18:31:03 up 17 min, 1 user, load average: 0.00, 0.00, 0.00
USER TTY FROM LOGIN@ IDLE JCPU PCPU WHAT
ubuntu pts/0 18.206.107.29 18:27 6.00s 0.07s ? w
w is part of the procps package which has been updated, it only used utmp as one of the source for findings
Lessons and Closing
I posted a comment for the bug https://bugs.launchpad.net/ubuntu/+source/coreutils/+bug/2130814
I believe there will be plenty of people who would hit this problem, hopefully this helps them.
The main problem here was not an error message, it was the empty response any workflow would get disturbed and updated with an error but the empty output could make problems way worse. So if you encounter problem the alternatives are w or loginctl list-sessions
Top comments (0)