Read Linux Login Records Safely with utmp and wtmp

A login record file cannot tell you who broke in, only who the system thinks logged in, and that gap turns a stale wtmp line into a false alarm. This guide gets you a reliable way to see current sessions, inspect recent login history, and tell a data-integrity problem apart from a display problem. The examples follow the behaviour of Linux man-pages 6.7, from Debian package manpages version 6.7-2 on this machine.

Allow about ten minutes. You need a shell and the ordinary commands who, last, stat and, if you want raw records, utmpdump. The inspection steps are read-only and do not need elevated privileges.

1. Check the Two Record Files

Linux keeps current-session information in /var/run/utmp and accumulated login and logout history in /var/log/wtmp. Check that both files exist before interpreting command output:

$ stat -c '%n %F %a %U:%G %s bytes' /var/run/utmp /var/log/wtmp
/var/run/utmp regular file 664 root:utmp 5376 bytes
/var/log/wtmp regular file 664 root:utmp 1041408 bytes

Your owner, group, permissions and sizes will differ. A missing wtmp means its record-keeping is off: the programs that maintain it do not create the file themselves. Do not create, truncate or replace either file merely to make a command produce output.

Checkpoint: If /var/run/utmp is absent on Linux, stop and investigate the service or package that normally maintains it. The man page says Linux utmp must always exist.

2. See Sessions Currently Recorded in utmp

Run who for the usual human-readable view:

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

Each line is derived from a USER_PROCESS record, normally giving a username, terminal line, login time and, for a remote session, a host value. The file can contain more than the users shown: not every programme logs through utmp, and the file also contains non-user record types such as boot, run-level, login-process and dead-process entries.

Do not treat who as a complete security inventory. It reports what the record file says, not every process, network connection or authenticated identity on the system.

3. Read Historical Logins from wtmp

Use last when the question is about previous sessions rather than current ones:

$ last -n 3
alice    pts/4        tmux(1998).%185  Sun Sep 27 17:24 - 17:24  (00:00)
alice    pts/1        198.51.100.49    Sun Sep 27 17:24 - 17:25  (00:00)
alice    pts/3        tmux(1998).%184  Sun Sep 27 16:45   still logged in

wtmp begins Fri Jun 12 00:07:47 2026

The -n 3 option limits the display to three records; without it, output can be long. A blank username in wtmp represents a logout on the associated terminal. Special terminal names record shutdown, reboot and system clock changes, so not every line is a person logging in.

Checkpoint: Compare an unexpected last entry with the source address shown by who, then check the system's authentication logs. A utmp or wtmp line alone is not proof of an account compromise.

4. Inspect the Raw utmp Records When the Summary Is Ambiguous

utmpdump shows the fixed-width records and their type numbers. This is useful when who hides a dead, login-process or boot entry:

$ utmpdump /var/run/utmp | head -8
Utmp dump of /var/run/utmp
[2] [00000] [~~  ] [reboot  ] [~           ] [6.8.0-139-generic   ] [0.0.0.0        ] [2026-09-11T14:58:41,014846+00:00]
[6] [01225] [tty1] [LOGIN   ] [tty1        ] [                    ] [0.0.0.0        ] [2026-09-11T14:59:13,059298+00:00]
[7] [2533405] [ts/0] [alice   ] [pts/0       ] [203.0.113.98        ] [203.0.113.98   ] [2026-09-27T10:12:11,284335+00:00]

The first bracket is the record type: 2 is boot time, 6 is a login process and 7 is a normal user process. The exact formatting belongs to the installed utmpdump, not to the utmp(5) file specification, so use the command's own help if your package formats fields differently.

Do not edit this output and feed it back to the file unless you have a specific recovery procedure for your distribution. The file is a binary sequence of C structures, and its format is machine-dependent.

5. Keep the Files Protected

The most serious rule in utmp(5) is about integrity: utmp must not be writable by the "other" class. System programmes depend on its contents, so broad write permission can enable forged records and changes to files that trust those records.

Inspect permissions without changing them:

$ stat -c '%n %a %U:%G' /var/run/utmp /var/log/wtmp
/var/run/utmp 664 root:utmp
/var/log/wtmp 664 root:utmp

The sample mode gives the owner and group write access, but not "other". Your distribution may choose different safe ownership or modes. If the final digit is 2, 6 or 7, stop and ask why before changing anything.

Warning: Permission changes are elevated, security-sensitive state changes; do not apply a guessed chmod fix to a live system. Record the current mode first and use your distribution's package or service documentation to restore the intended ownership and mode.

6. Know What Not to Change

Do not remove /var/run/utmp to hide a user from who. Unlike some other systems, Linux expects utmp to exist. Do not clear the ut_id field in a custom program either: the man page warns that doing so can introduce races, corrupt records and security holes.

If you are writing software, include <utmp.h> and use the libc interfaces described in getutent(3), getutmp(3), login(3) and updwtmp(3) rather than assuming that a structure copied from another Unix is compatible. Linux's structure is machine-dependent and its utmpx structure is defined to match utmp; POSIX does not specify Linux's utmp layout or field lengths.

Done means