Bug 2343998 - who -m prints no output
Summary: who -m prints no output
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: coreutils
Version: rawhide
Hardware: All
OS: All
unspecified
low
Target Milestone: ---
Assignee: Lukáš Zaoral
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2025-02-05 17:04 UTC by jstephen
Modified: 2025-03-15 00:31 UTC (History)
10 users (show)

Fixed In Version: coreutils-9.6-2.fc43 coreutils-9.6-2.fc42
Clone Of:
Environment:
Last Closed: 2025-02-25 18:08:48 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

Description jstephen 2025-02-05 17:04:00 UTC
Description of problem:
'who -m' or 'who am i' no longer prints output.

Version-Release number of selected component (if applicable):
coreutils-9.6-1.fc42.x86_64

How reproducible:
Always

Steps to Reproduce:
1. run 'who -m'
2.
3.

Actual results:
# who -m
# 


Expected results:
# who am i
root     pts/0        2025-02-05 11:35 (10.22.64.138)

Comment 1 Lukáš Zaoral 2025-02-06 13:14:54 UTC
Thank you for the report!  I can reproduce this on F42+ when I login through SSH (direct logins, e.g. through serial work for me already):

$ who
lzaoral  sshd pts/0   2025-02-04 08:43 (10.0.2.2)
lzaoral  sshd pts/1   2025-02-04 10:35 (10.0.2.2)
lzaoral  sshd pts/2   2025-02-04 11:48 (10.0.2.2)
lzaoral  sshd pts/3   2025-02-04 12:45 (10.0.2.2)
lzaoral  sshd pts/4   2025-02-05 10:07 (10.0.2.2)
lzaoral  sshd pts/5   2025-02-05 12:09 (10.0.2.2)
lzaoral  sshd pts/6   2025-02-05 13:25 (10.0.2.2)
lzaoral  sshd pts/7   2025-02-05 18:05 (10.0.2.2)

$ tty
/dev/pts/6

$ who -m; who am i
$

It is caused by the fact that coreutils in Fedora now use logind to get the necessary information.  The readutmp module in gnulib will concatenate the service and with the guessed associated pty device for the given session (I have used "guess" because, unfortunately, logind cannot provide the tty info for sshd directly, see: https://github.com/systemd/systemd/issues/26611).  The who command was never extended to account for this possibility (service account string concatenated with a guessed pty device) so that is the reason why 'who -m' fails to select the correct entry as witnessed by ltrace:

$ ltrace -e strcmp@who who -m
... // unrelated strcmp calls
who->strcmp("tty", "tty")                                                                                            = 0
who->strcmp("pts/6", "~")                                                                                            = -14
who->strcmp("pts/6", "sshd pts/0")                                                                                   = -3
who->strcmp("pts/6", "sshd pts/1")                                                                                   = -3
who->strcmp("pts/6", "sshd pts/2")                                                                                   = -3
who->strcmp("pts/6", "sshd pts/3")                                                                                   = -3
who->strcmp("pts/6", "sshd pts/4")                                                                                   = -3
who->strcmp("pts/6", "sshd pts/5")                                                                                   = -3
who->strcmp("pts/6", "sshd pts/6")                                                                                   = -3
who->strcmp("pts/6", "sshd pts/7")                                                                                   = -3
+++ exited (status 0) +++

So the solution should be to only match the suffix (patch is for upstream and v9.6):

diff --git a/bootstrap.conf b/bootstrap.conf
index 380fa1120..c99838e95 100644
--- a/bootstrap.conf
+++ b/bootstrap.conf
@@ -253,6 +253,7 @@ gnulib_modules="
   stdckdint-h
   stdlib-safer
   stpcpy
+  str_endswith
   strdup-posix
   strnlen
   strnumcmp
diff --git a/src/who.c b/src/who.c
index 8bfed53d6..218d32181 100644
--- a/src/who.c
+++ b/src/who.c
@@ -583,7 +583,7 @@ scan_entries (idx_t n, struct gl_utmp const *utmp_buf)
   while (n--)
     {
       if (!my_line_only
-          || STREQ (ttyname_b, utmp_buf->ut_line))
+          || str_endswith(utmp_buf->ut_line, ttyname_b))
         {
           if (need_users && IS_USER_PROCESS (utmp_buf))
             print_user (utmp_buf, boottime);

... which fixes the issue for me:

$ src/who -m
lzaoral  sshd pts/6   2025-02-05 13:25 (10.0.2.2)

Comment 3 Lukáš Zaoral 2025-02-24 11:18:00 UTC
I've sent the patch to the coreutils ML: https://lists.gnu.org/archive/html/coreutils/2025-02/msg00014.html

Comment 4 Fedora Update System 2025-02-25 16:37:52 UTC
FEDORA-2025-54e06486f1 (coreutils-9.6-2.fc43) has been submitted as an update to Fedora 43.
https://bodhi.fedoraproject.org/updates/FEDORA-2025-54e06486f1

Comment 5 Fedora Update System 2025-02-25 16:48:59 UTC
FEDORA-2025-9456cc2f00 (coreutils-9.6-2.fc42) has been submitted as an update to Fedora 42.
https://bodhi.fedoraproject.org/updates/FEDORA-2025-9456cc2f00

Comment 6 Fedora Update System 2025-02-25 18:08:48 UTC
FEDORA-2025-54e06486f1 (coreutils-9.6-2.fc43) has been pushed to the Fedora 43 stable repository.
If problem still persists, please make note of it in this bug report.

Comment 7 Fedora Update System 2025-02-26 02:33:53 UTC
FEDORA-2025-9456cc2f00 has been pushed to the Fedora 42 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2025-9456cc2f00`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2025-9456cc2f00

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

Comment 8 Fedora Update System 2025-03-15 00:31:08 UTC
FEDORA-2025-9456cc2f00 (coreutils-9.6-2.fc42) has been pushed to the Fedora 42 stable repository.
If problem still persists, please make note of it in this bug report.


Note You need to log in before you can comment on or make changes to this bug.