FreeBSD UTX Accounting: Reconcile Active Sessions and Login History

FreeBSD records login and session events in its UTX accounting database. The active-session view supports commands such as who and w; the historical log supports last; and a separate last-login database is used by lastlogin(8). These utilities answer different questions. “Who is logged in now?”, “What sessions were recorded?”, and “When did each account last log in?” are not interchangeable views of one file.

UTX is useful for operations, capacity planning, and incident triage, but it is not tamper-proof evidence. A privileged administrator can change local records, log rotation or truncation can remove history, and an application crash can leave a session entry that was not cleanly closed. Correlate it with service logs, process state, remote authentication records, and time synchronization before making attribution claims.

Establish the active and historical data sources

Record the current time basis and inspect the known UTX files:

date -u
who
w
ls -l /var/run/utx.active /var/log/utx.log /var/log/utx.lastlogin

who normally reads /var/run/utx.active; last reads /var/log/utx.log; lastlogin uses /var/log/utx.lastlogin. File presence and size are only a starting point. The active database is expected to change as sessions start and end, while history retention depends on local rotation and cleanup policy.

Use who for the current active-record view:

who -aH
who -q
who am i

The default output includes login name, terminal, login time, and remote host when available. who -q produces a compact list and count; who am i reports the terminal attached to standard input. w adds activity context such as idle time and what users are doing, but it is still a snapshot of current sessions, not a complete action log.

Reconstruct recorded history with last

Use last to review recorded logins and logouts in reverse chronological order:

last -n 30 -y
last -t ttyv0 -n 20
last root -n 20

The command reports user, terminal, host when present, start and stop time, and duration. A session that remains open or was cut short by a crash or shutdown is represented accordingly. The manual notes that if a login shell terminates abnormally, a logout record may be missing and last can show the ending as a shutdown. Do not interpret an open-ended or shutdown-marked session as proof that a user was actively connected at the current instant.

To examine a rotated file explicitly, specify it with -f:

last -f /var/log/utx.log.0 -n 50

Confirm rotation naming and compression policy first. If the file is compressed, consult the local toolchain and preserve the original; do not feed an arbitrary compressed file to last and assume the output is complete. If there are multiple rotations, inspect each in chronological order and record gaps caused by retention.

lastlogin is a different report:

lastlogin -t root serviceuser

It reports the last recorded login for specified users or all users, sorted according to its options. Its database is not a full session history and is not normally turned over or deleted in standard usage. A user with no record is not necessarily evidence that an account was never used; files may be migrated, restored, or selectively maintained.

Understand records and identifiers

The UTX database has active sessions and event records for login, logout, reboot, shutdown, and date changes. who can read either its default active file or an alternate file. When pointed at /var/log/utx.log, it interprets historical events and can display empty names or special markers for logout and system events. Those markers are part of the record format; do not treat every line as a username.

For stale active sessions, utx(8) documents getent utmpx active as a way to display active records including identifiers:

getent utmpx active
who
w

Compare the identifier and terminal with current process and service state before cleanup. A session may be maintained by a login service, pseudo-terminal manager, or another program. Do not assume that an old login time alone means the record is stale; a long-running shell can legitimately remain idle.

utx rm identifier removes a stale session record and requires superuser access. Use it only after confirming the session owner process is gone, the terminal is no longer active, the identifier matches the stale record, and the record is not part of a running service’s state. Capture the getent result and incident context before removal. Do not use utx rm to hide an unfamiliar session or to clean up every old-looking entry.

The utx boot and utx shutdown actions write system events and are normally used by rc(8). Administrators should not invoke them manually to fabricate or repair history. If the host’s event sequence is inconsistent, preserve the files and investigate the shutdown path, boot scripts, and time configuration.

Distinguish session records from process accounting

UTX records login-session events; process accounting records command execution and resource use. FreeBSD’s acct(8) and lastcomm(1) tooling serve a different data source and require their own configuration and retention. A user can have a UTX session without process accounting being enabled, and process accounting data does not replace login/logout records.

For an incident timeline, correlate at least the account, terminal or remote host, process tree, system log entries, and UTC time. Terminal names can be reused after a session exits. Usernames can be renamed or removed. Remote host fields may be absent or reflect the authentication endpoint rather than an original client behind a proxy. Preserve raw records before using a human-readable summary as evidence.

Check clock changes carefully. The history can include date-change events, and a poorly synchronized machine can make timestamps appear out of order relative to a central log collector. Convert times to UTC only after identifying the timezone and offset in effect; do not silently reinterpret ambiguous local times. UTX text output is a display representation, not a cryptographically signed timestamp.

Plan retention and protect the record set

The historical log can grow, and the who(1) manual notes that sites may keep daily versions or remove them after compression. Check which component owns rotation on the host and avoid configuring two rotators for the same UTX database. A generic text-log rotation policy may not be safe for a structured accounting file if writers expect a particular active path or format.

Before adjusting retention, determine operational and legal requirements, expected login volume, disk space, and backup scope. Verify restored records with the same FreeBSD utilities used during incident response. Keep permissions restrictive enough for the system’s intended readers and preserve backups on a trusted system if evidence must survive host compromise. Local root can alter these files, so external log shipping is required for stronger tamper resistance.

Avoid exporting full login histories into broadly accessible dashboards. They contain usernames, terminal identifiers, remote hostnames, and activity times. Limit access to the operational need and define an expiration period consistent with retention policy. A report that is convenient to query can still be sensitive.

Diagnose common discrepancies

If who shows a user but no matching process is visible, inspect the terminal and session identifier, then check ps, fstat, and the login service. The record may be stale, the shell may have exited unexpectedly, or the process may run in a jail or different terminal context. Confirm before deleting.

If last has no expected entry, verify that you are reading the correct file and rotation, that the user authenticated through a path that writes UTX events, and that history was not truncated or restored from an older backup. A custom application can have its own audit trail without creating ordinary login records.

If the times differ from syslog, first compare UTC offsets, host clocks, and date-change events. Then compare raw source records and log-collector timestamps. A UTX entry and a syslog line can be correct representations of different clock or timezone policies.

Acceptance criteria

A session reconciliation is complete when the active view, historical range, file paths, time zone, and source limitations are documented. A stale record is removed only after its owning process and terminal are confirmed inactive, its exact identifier is matched, and cleanup is captured. An incident conclusion correlates UTX with independent logs and avoids treating local accounting as tamper-proof.

Use who, w, last, lastlogin, and utx according to the specific question each answers. Preserve raw records, understand retention, and reconcile the same event across multiple sources rather than over-reading one command’s output.

Related:

Sources: