Verify systemd's boot and runlevel utmp services

You will finish with a safe way to inspect the two systemd services that write boot, shutdown and runlevel records, confirm which one is active, and investigate 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 require 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 also update the audit logs as described by 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 is actually using. 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 remains shown as active (exited) after its start action has completed. Both units are static in 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 not be active between transitions. The boot and shutdown unit's active (exited) state means its start action returned successfully; it is not a long-running daemon.

For a machine-readable view of the relevant fields, use:

$ 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 the who utility is installed, inspect the current login records:

$ who

Use last to read historical wtmp entries when that utility 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 the cause. First check whether the file exists and is readable:

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

Do not truncate, remove or recreate the file as a first diagnostic step. Those actions destroy evidence and can affect other accounting tools.

5. Read the service journal when state is failed

If status reports a failure, inspect this boot's messages. Reading the journal may need membership of the journal-reading group 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 such as 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.

6. Avoid unsafe manual tests

Starting or stopping these units manually can write accounting records at the wrong time. Stopping the boot and shutdown unit is particularly 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 make the status change.

There is also no useful undo for a false accounting record: the event has already been written to the accounting files. If you need to reproduce a failure, use a disposable virtual machine and take a snapshot first. On the real host, fix the specific mount, permission or audit problem identified in the journal, then let the normal boot or target lifecycle invoke the units.