Read Linux Login History Safely with wtmp and utmpdump

You will finish with a practical way to inspect the login history on a Linux machine, identify the files that provide it, and tell ordinary session records from reboots and clock changes. The examples are read-only. They do not edit the log, change retention, or alter login services.

This guide uses Linux man-pages 6.7, supplied by Debian package manpages version 6.7-2, and util-linux last 2.42.4 with utmpdump. Allow about ten minutes. You need a shell and read access to /var/log/wtmp; elevated privileges are only needed if your account cannot read that file.

1. Understand what wtmp records

wtmp is a historical record. It stores login and logout entries in the same machine-dependent record format used by utmp, which describes current users. On this system the usual paths are /var/log/wtmp for history and /var/run/utmp for current sessions.

A null username represents a logout on the associated terminal. The special terminal name ~, paired with the username shutdown or reboot, represents a shutdown or reboot. The terminal names | and } mark the old and new system time when date changes the clock.

Not every connection is guaranteed to appear. The manpage says that wtmp is maintained by login, init and some getty implementations. A program that does not write utmp records will not create a complete audit trail here.

2. Confirm the files before reading them

Check the installed paths and their permissions without changing anything:

$ stat -c '%A %U %G %s %y %n' /var/log/wtmp /var/run/utmp
-rw-rw-r-- root utmp 1062912 2026-09-28 10:07:58.682667522 +0100 /var/log/wtmp
-rw-rw-r-- root utmp 5760 2026-09-28 10:07:58.682667522 +0100 /var/run/utmp

Your size and timestamp will differ. The useful checks are that the expected path exists, the file is not unexpectedly world-writable, and your account can read it. Use test if you want a quiet permission check:

$ test -r /var/log/wtmp && echo 'wtmp is readable'
wtmp is readable

If this fails, ask an administrator to grant appropriate read access or use sudo for the single read command. Do not fix it by making the file writable. The manpage warns that utmp integrity matters to system programs and that unsafe permissions can permit forged records or other modifications.

3. Read a concise session history with last

last turns the records into a session-oriented report. Limit the output while you are exploring:

$ last -n 5 -f /var/log/wtmp
andy     pts/3        tmux(1998).%212  Mon Sep 28 10:06 - 10:07  (00:01)
andy     pts/4        tmux(1998).%211  Mon Sep 28 09:45 - 09:45  (00:00)
andy     pts/3        tmux(1998).%210  Mon Sep 28 09:22 - 09:52  (00:29)
andy     pts/10       tmux(1998).%209  Mon Sep 28 09:16 - 09:16  (00:00)
andy     pts/9        tmux(1998).%208  Mon Sep 28 09:16 - 09:16  (00:00)

These lines are examples from one machine, not a fixed output contract. User, terminal, host, time zone and formatting will vary. The final summary line is also useful: last reports when the wtmp file begins. A line ending in still logged in represents a current session; a duration shows a completed interval.

For the installed reader, record the version when a report needs to be reproduced:

$ last --version
last from util-linux 2.42.4

4. Inspect raw records with utmpdump

Use utmpdump when the summary hides a detail, or when you need to distinguish record types. This is still read-only:

$ utmpdump /var/log/wtmp | head -n 8
Utmp dump of /var/log/wtmp
[8] [949143] [    ] [        ] [pts/0       ] [                    ] [0.0.0.0        ] [2026-06-11T23:07:47,786264+00:00]
[8] [1003000] [    ] [        ] [pts/5       ] [                    ] [0.0.0.0        ] [2026-06-11T23:58:35,208171+00:00]
[7] [1903087] [ts/0] [andy    ] [pts/0       ] [150.228.103.105     ] [150.228.103.105] [2026-06-12T06:28:57,332930+00:00]
[7] [2215216] [ts/5] [andy    ] [pts/5       ] [tmux(2215216).%32   ] [0.0.0.0        ] [2026-06-12T06:28:58,044084+00:00]
[8] [2215216] [ts/5] [andy    ] [pts/5       ] [                    ] [0.0.0.0        ] [2026-06-12T06:28:58,049694+00:00]
[7] [1944407] [ts/5] [andy    ] [pts/5       ] [151.186.181.120     ] [151.186.181.120] [2026-06-12T06:52:45,643056+00:00]
[7] [2215216] [ts/7] [andy    ] [pts/7       ] [tmux(2215216).%33   ] [0.0.0.0        ] [2026-06-12T06:52:45,857144+00:00]

The first numeric field is the record type from <utmp.h>. Type 7 is USER_PROCESS, a normal session. Type 8 is DEAD_PROCESS, normally the cleanup record for a terminated process. Other values include boot time, run-level changes and clock changes. The exact columns are a dump of the binary structure, so use last for a readable report and utmpdump for investigation.

Do not use utmpdump --reverse while investigating. That option writes dumped records back to an utmp or wtmp file. It is a state-changing operation and can corrupt history if the input, format or destination is wrong. There is no useful undo for a damaged log. Keep the command in its default read mode unless you have a specific, documented recovery task and a verified backup.

5. Check current users separately

Historical wtmp data and current utmp data answer different questions. Use who for the sessions currently represented in /var/run/utmp:

$ who
andy     pts/3        2026-09-28 10:06 (tmux(1998).%212)

A difference between who and recent last output is normal. One is a current snapshot, while the other includes completed sessions and records that may have been written by different login or terminal programs.

6. Avoid disabling or weakening the record

There is no wtmp configuration file in this interface. The manpage states that the maintaining programs do not create /var/log/wtmp; if it is removed, record-keeping is turned off. That is a service and auditability change, not a cleanup shortcut.

Do not delete, truncate, rewrite or chmod the files as part of this guide. If the file is growing too large, investigate the system's log rotation policy separately, preserve the old records according to your retention requirements, and test the replacement before relying on it.

If you accidentally changed a file, stop further writes only if your incident procedure requires it, restore from a known-good backup, and verify with last and utmpdump. Do not invent records to fill a gap.

The format is machine-dependent. Process a wtmp file on the architecture that created it, and avoid treating its binary layout as a portable interchange format. If you write software against it, include <utmp.h> and use the structure supplied by that machine's libc rather than copying a structure definition into an application.