Read Linux Login Sessions Clearly with who(1)

You will use who to answer the practical questions: who is logged in, which terminal they are using, when the session started, and whether a terminal accepts messages. You will also inspect boot, runlevel and login-process records without changing the system.

Allow about ten minutes. You need a shell on a Linux machine with GNU coreutils installed. The examples below were checked with GNU coreutils 9.4. Output is live session data, so usernames, times and remote addresses will differ on your machine.

1. Check the installed command

Start by confirming which executable your shell will run and which version supplies it:

$ command -v who
/usr/bin/who
$ who --version | head -2
who (GNU coreutils) 9.4
Copyright (C) 2023 Free Software Foundation, Inc.

The exact path and version can differ. Keep the version with any incident notes because option details and output formatting belong to the installed release.

2. List the ordinary login sessions

Run who with no option for the normal short report:

$ who
andy     pts/0        2026-09-27 11:12 (9.246.33.98)
andy     pts/2        2026-09-27 13:00 (tmux(1998).%172)

Each row normally contains a login name, terminal line, login time and an optional comment such as a remote host or terminal multiplexer identifier. The default is the short form, equivalent to asking for name, line and time. The displayed sessions can change while you are reading them.

Add headings when the output will be handed to somebody else:

$ who --heading
NAME     LINE         TIME             COMMENT
andy     pts/0        2026-09-27 11:12 (9.246.33.98)
andy     pts/2        2026-09-27 13:00 (tmux(1998).%172)

Checkpoint: identify the session you mean

• NAME is the account recorded in the login database.
• LINE is the terminal, such as pts/0 or tty1.
• TIME is the recorded login time, not necessarily the time of the last command.
• A parenthesised value is commonly the remote host or another session comment.

Treat this as observational data. Do not infer that a listed user is actively typing, or that a remote address proves who is physically using the account.

3. Count users, or inspect the session attached to standard input

Use --count when you need login names followed by a total:

$ who --count
andy andy
# users=2

This counts entries in the login database, so repeated names can be legitimate when one account has several sessions. It is not a count of distinct account names unless you process the output yourself.

Use -m when the question is specifically about the hostname and user associated with standard input:

$ who -m
andy     pts/0        2026-09-27 11:12 (9.246.33.98)

The traditional spellings who am i and who mom likes are treated the same way by this implementation. The result depends on the terminal attached to standard input, so a command run through a pipe, scheduler or automation runner may produce no useful row.

4. Add message status when terminal access matters

Use -T, also written -w or --mesg, to add a message-status column:

$ who --mesg
andy     + pts/0        2026-09-27 11:12 (9.246.33.98)
andy     - pts/2        2026-09-27 13:00 (tmux(1998).%172)

A plus sign means messages are permitted on that terminal, a minus sign means they are not, and a question mark means the status cannot be determined. This is a property of the terminal record, not permission to bypass another user's access controls.

5. Inspect boot, runlevel and process records

Use --all for a broad report. It combines boot time, dead processes, login processes, active processes spawned by init, runlevel, clock-change time, message status and logged-in users:

$ who --all
           system boot  2026-09-11 15:58
LOGIN      tty1         2026-09-11 15:59              1225 id=tty1
andy     + pts/0        2026-09-27 11:12 00:44     2533405 (9.246.33.98)
           run-level 5  2026-09-11 16:15

The full report can be long and its columns vary by record type. For a focused check, choose one option instead:

• --boot reports the last system boot.
• --runlevel reports the current runlevel record.
• --login reports system login processes.
• --process reports active processes spawned by init.
• --dead reports dead processes.
• --time reports the last system clock change.

Do not treat an absent record as proof that the underlying event never happened. These reports reflect what the login database contains, and some systems or session managers record different events.

6. Read a specific login database file

With no file argument, who reads /var/run/utmp. /var/log/wtmp is a common alternate file, especially when investigating historical records:

$ who /var/log/wtmp
andy     pts/0        2026-09-27 11:12 (9.246.33.98)
andy     pts/2        2026-09-27 13:00 (tmux(1998).%172)

Use a real path from your system, and check it before running the command:

$ test -r /var/log/wtmp && echo "readable"
readable

Reading these files normally needs no elevated privilege when your account can read them. If a file is protected, do not casually broaden its permissions. Use your organisation's approved administrative method, and remember that the output may disclose account names, terminal activity and host information.

7. Avoid the common traps

who reads records; it does not discover every process, repair a stale session, log a user out or prove that a network connection is healthy. A stale row needs investigation of the session manager and login database, not deletion of an arbitrary file.

For scripts, prefer a narrow option and parse the format you have tested. Avoid depending on column positions from --all, because different record types have different fields. Use --lookup only when you specifically want an attempt to canonicalise hostnames through DNS. DNS can be slow or unavailable, and a failed lookup does not make the session record invalid.

No command in this guide changes state, so there is no undo step. Do not add sudo merely because a row looks surprising.