Verify systemd's Boot and Runlevel UTMP Services

When an audit tool disagrees about when the machine last rebooted, the answer usually lives with systemd-update-utmp.service and its runlevel sibling. This guide gives you a safe way to inspect them, confirm which one is active, and check the usual storage or audit prerequisites. The examples are read-only: they do not reboot the machine, change a target, or edit /var/log/wtmp.

Allow about ten minutes. You need a shell and a systemd host. Some status and journal details may need elevated privileges, but the inspection commands themselves are harmless. This guide was checked against Ubuntu's systemd package version 255.4-1ubuntu8.17, whose installed manpage identifies systemd 255.

1. Understand which service does what

There are two related units, and their names are easy to conflate:

• systemd-update-utmp.service records system boot and shutdown events.
• systemd-update-utmp-runlevel.service records SysV runlevel changes.

Both write records to utmp and wtmp, and update the audit logs as described in the installed manual. The first unit runs the helper with reboot when started and shutdown when stopped. The runlevel unit runs it with runlevel. These are system-managed lifecycle hooks, not commands you normally invoke by hand.

2. Confirm the installed package and unit files

Check the version and ask systemd to print the units it actually uses. These commands do not need root:

$ dpkg-query -W -f='${Package} ${Version}\n' systemd
systemd 255.4-1ubuntu8.17
$ systemctl cat systemd-update-utmp.service systemd-update-utmp-runlevel.service

Look for Type=oneshot. The main unit has RemainAfterExit=yes, so it normally shows as active (exited) once its start action has completed. Both units are static on this installation: they are pulled into boot or target ordering by dependencies rather than enabled with an ordinary systemctl enable workflow.

The unit files also show important boundaries: they require mounts for /var/log/wtmp, order around auditd.service where appropriate, and conflict with shutdown.target. Do not copy the ExecStart lines into an ad-hoc shell script; they are part of systemd's dependency and shutdown ordering.

3. Check current state without starting anything

Request concise status for both services:

$ systemctl status --no-pager systemd-update-utmp.service systemd-update-utmp-runlevel.service

On a normally booted host, a representative result is:

systemd-update-utmp.service - Record System Boot/Shutdown in UTMP
     Loaded: loaded (.../systemd-update-utmp.service; static)
     Active: active (exited)

systemd-update-utmp-runlevel.service - Record Runlevel Change in UTMP
     Loaded: loaded (.../systemd-update-utmp-runlevel.service; static)

The exact timestamps, process IDs and active state vary. An inactive runlevel unit is not automatically an error: it is a oneshot hook for a runlevel transition and may sit inactive between them. The boot and shutdown unit's active (exited) state means its start action returned successfully, not that it is a long-running daemon.

For a machine-readable view of the relevant fields:

$ systemctl show --no-pager \
    -p LoadState -p ActiveState -p SubState -p UnitFileState \
    systemd-update-utmp.service systemd-update-utmp-runlevel.service

4. Inspect the records without changing them

The services use the standard utmp and wtmp facilities. If who is installed, inspect current login records:

$ who

Use last to read historical wtmp entries when it is available:

$ last -x -n 20

Output depends on the host's history and retention: you may see boot, shutdown or runlevel entries, but an empty or short history is not enough by itself to identify a cause. First check whether the file exists and is readable:

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

5. Read the service journal when state is failed

If status reports a failure, inspect this boot's messages. Reading the journal may need journal-reading group membership or elevated privileges:

$ journalctl -b -u systemd-update-utmp.service \
    -u systemd-update-utmp-runlevel.service --no-pager

If access is denied, rerun the same read-only command with sudo only if your account is authorised:

$ sudo journalctl -b -u systemd-update-utmp.service \
    -u systemd-update-utmp-runlevel.service --no-pager

Look for a concrete cause: an unavailable /var/log/wtmp mount, a permission or filesystem error, or a message from the audit interface. Do not infer that the helper is broken merely because the runlevel unit is currently inactive.

Common traps

• Testing by starting or stopping the units manually. That can write accounting records at the wrong time. Stopping the boot and shutdown unit is especially misleading because its ExecStop action is the shutdown update: do not run systemctl stop systemd-update-utmp.service or trigger a target transition just to watch the status change.
• Expecting an undo for a false accounting record. There is none; the event is already written to the accounting files. To reproduce a failure, use a disposable virtual machine and snapshot it first. On the real host, fix the specific mount, permission or audit problem the journal identifies, then let the normal boot or target lifecycle invoke the units.