Read Linux Login History Safely with wtmp

Something logged into a box at 3am, and wtmp is the file that tells you who, from where, and whether it lines up with a reboot. last and utmpdump read that history without touching a thing. Every example below is read-only: none of them edit the log, change retention, or alter login services.

The route

Jump straight to the step you need, or tick off Done means at the end.

1. Understand what wtmp records
2. Confirm the files before reading them
3. Read a concise session history with last
4. Inspect raw records with utmpdump
5. Check current users separately
6. Avoid disabling or weakening the record

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

Checkpoint

If you only need a human-readable list of recent sessions, jump to step 3. The earlier steps explain what the file is and prevent common mistakes.

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 terminal name ~, paired with 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 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 for a quiet permission check:

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

Tip

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
alice    pts/3        tmux(1998).%212  Mon Sep 28 10:06 - 10:07  (00:01)
alice    pts/4        tmux(1998).%211  Mon Sep 28 09:45 - 09:45  (00:00)
alice    pts/3        tmux(1998).%210  Mon Sep 28 09:22 - 09:52  (00:29)
alice    pts/10       tmux(1998).%209  Mon Sep 28 09:16 - 09:16  (00:00)
alice    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.

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] [alice   ] [pts/0       ] [203.0.113.42        ] [203.0.113.42   ] [2026-06-12T06:28:57,332930+00:00]
[7] [2215216] [ts/5] [alice   ] [pts/5       ] [tmux(2215216).%32   ] [0.0.0.0        ] [2026-06-12T06:28:58,044084+00:00]
[8] [2215216] [ts/5] [alice   ] [pts/5       ] [                    ] [0.0.0.0        ] [2026-06-12T06:28:58,049694+00:00]
[7] [1944407] [ts/5] [alice   ] [pts/5       ] [198.51.100.77       ] [198.51.100.77  ] [2026-06-12T06:52:45,643056+00:00]
[7] [2215216] [ts/7] [alice   ] [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.

Warning

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
alice    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.

Warning

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.

Recovery

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.

Done means

Files identified. You know /var/log/wtmp as historical login and logout data and /var/run/utmp as the current-session file.
Permissions checked. You confirmed file permissions and read access without weakening them.
Concise report used. You ran last -n 5 -f /var/log/wtmp for a quick view.
Detail available. You used utmpdump in its default read-only mode when record details mattered.
Concepts kept separate. Current sessions, historical records and incomplete coverage stayed distinct.
Nothing altered. You did not delete, truncate or rewrite the machine-dependent files.