utmp

/run/utmp (also reachable as /var/run/utmp) lists the sessions open right now. It is read by who, w and users, and written by login, sshd and other programs through PAM or the utmp functions of the C library. It holds one record per active terminal session, plus the current boot and run level records.

utmp is also the name of the record structure, struct utmp, shared with wtmp and btmp: type (ut_type), PID, terminal (ut_line), user, remote host, time and remote address. The record is 384 bytes on x86_64 and 400 bytes on aarch64. A login is a USER_PROCESS record (type 7); when the session ends the slot is reused with DEAD_PROCESS (type 8).

Why it matters in investigations

Because /run is a tmpfs, utmp exists only on a running system: it is cleared at every boot and gone from a powered-off disk image. Collected live, it answers a question the other sources answer only indirectly: who is logged in at this moment, on which terminal, from which address. That is useful when an intruder may still be connected, and for spotting sessions that were never recorded in wtmp. Remember that non-interactive SSH (a remote command, scp, sftp) does not allocate a terminal and usually has no utmp record, and that root can edit the file like any other.

Example

On a live host, as root:

who -a                        # boot time, run level and current logins
utmpdump /run/utmp            # every record, including DEAD_PROCESS slots
cp -p /run/utmp /media/evidence/utmp

Copy the file itself rather than only the command output, and note the architecture of the host: an aarch64 utmp read with tools on an x86_64 workstation will be misread.

Related terms

• wtmp and btmp: the login history in the same format.
• lastlog: the last login per UID.
• UAC: collects /run/utmp in its triage profile.

Linux Log Parser reads utmp in both record sizes. More in wtmp, btmp and lastlog forensics.