FreeBSD Process Accounting: Enable, Query, and Retain acct Records

FreeBSD process accounting records selected facts about processes when they terminate. The kernel appends a compact accounting record to a file when accounting is enabled; lastcomm and sa provide human-readable views and summaries. This is useful for retrospective questions such as which command ran, under which account, and how much CPU time it consumed.

Accounting is not a live process monitor, a security audit trail, or a replacement for application logs. It generally cannot explain a process that is still running, preserve full command arguments, reconstruct what files were read, or record a process that never terminates normally. Use it as one bounded telemetry source with an explicit retention and privacy plan.

Decide what information you need

Before enabling accounting, define the incident questions it should answer, who can inspect the raw file, how long records should be retained, and how storage will be monitored. The command name field is short in the documented record format, and accounting records are not a complete shell history. Do not promise investigators that acct can recover arguments, environment variables, terminal input, or a precise event sequence that it does not record.

The record is appended at process termination under normal conditions. Crashes and reboots can prevent records for processes that did not terminate; long-running processes are not yet represented. These gaps are material during incident response. Pair process accounting with service logs, authentication records, process tracing, and application telemetry when a complete timeline is required.

Prepare the accounting file

The target file must exist before enabling accounting. Confirm the account directory and filesystem capacity first:

install -d -o root -g wheel -m 700 /var/account
install -o root -g wheel -m 600 /dev/null /var/account/acct
ls -ld /var/account
ls -l /var/account/acct
df -h /var/account

If /var/account already exists, do not reset its permissions blindly without checking local policy. The commands above are a new-file example; preserve existing raw and summary files. Choose a filesystem with enough space and monitoring. The raw file can grow by hundreds of blocks per day on a large system, depending on process volume and record format.

The process accounting file contains user activity metadata. Limit read access to trusted administrators, include it in backup and retention policies only if appropriate, and avoid copying it into broad diagnostics bundles. Confirm that your privacy and records policies permit its collection.

Enable accounting and confirm the writer

For a temporary test, invoke accton with the existing accounting file:

accton /var/account/acct

The utility enables the kernel facility and normally returns rather than remaining as a daemon. A process-list check is therefore not a reliable confirmation. Instead, run a short known command as a test user, allow it to exit, and query the resulting record.

For boot-time enablement, FreeBSD’s rc.conf(5) exposes accounting_enable. Set it with the site’s configuration process:

sysrc accounting_enable="YES"

The FreeBSD Handbook documents accounting_enable for boot-time startup through the accton facility. Verify persistence after a planned reboot by running a benign command, letting it exit, and checking lastcomm. The path used by startup must exist and be protected before reboot.

If you need to stop collection temporarily, run accton without a file argument:

accton

Before disabling, decide whether an incident is underway and whether the current raw file must be preserved. Avoid truncating or replacing the file while collection is active.

Read records with lastcomm

lastcomm reads the current accounting file and displays recorded command activity. Begin with a bounded view:

lastcomm -f /var/account/acct | head -50

The output can be filtered by command, user, or terminal according to lastcomm(1). It can also display process elapsed, user CPU, system CPU, and exit information with supported flags. These values reflect accounting records, not a measurement of wall time from an external tracing system.

A reliable test is to execute a command that exits, then query its name or user. Do not expect to find a command that is currently running. Do not infer that a command was never executed just because it is absent: accounting may have been disabled, records may have rotated, the process may not have terminated, or the observed name may be truncated in the accounting record.

For example, use a disposable test account and a benign command:

su -m nobody -c /usr/bin/true
lastcomm -f /var/account/acct true

The exact user-switching policy may differ, and a default system may not permit the unprivileged account to run a shell. Use a locally approved test account instead. Avoid testing with a production command that changes data.

Summarize with sa and preserve raw evidence

sa summarizes accounting data by command and user. Its reports can answer aggregate questions that a long raw listing does not, but its options can also maintain or condense accounting files. Read sa(8) before selecting flags and test against a copy when the integrity of the raw file matters.

sa -u /var/account/acct

The -u report is useful for reviewing per-record user and system CPU time, elapsed time, I/O usage, and command name. Depending on selected options, sa can update summary databases in /var/account. Document whether summary files are derived data that can be regenerated and which raw records are retained.

Do not run an unfamiliar sa option against the production file during an investigation. Copy the file to a secured analysis host or a restricted working directory, preserve timestamps and hashes according to evidence procedures, and test transformations on the copy first. A successful summary does not establish that raw records are complete or unmodified.

Plan growth, retention, and rotation

Accounting files are append-oriented evidence and can consume space continuously. Establish an alert on file size and free space, an owner for rotation, and a retention window. Do not delete an active accounting file while the kernel may be writing to it. Coordinate stop, archive, create, permissions, and restart operations through a tested procedure.

The simplest safe retention plan is to periodically disable collection, archive the closed file with restricted permissions, create a new empty file, restore ownership and mode, then re-enable accounting. A rotation script must handle failures so it does not leave accounting disabled or a writable file exposed. Test the exact script on a non-production host and verify that new records appear in the replacement file.

If raw archives are compressed, retain enough metadata to identify the host, time interval, FreeBSD release, accounting status, and file hash. Ensure that the compression and transfer process does not alter the original evidence before an investigation approves it. Keep summaries distinct from originals.

Interpret gaps and combine signals

Process accounting records command names and resource use, but not a full command line or file access history. Use ktrace or another tracing mechanism for a bounded, consented diagnostic that needs system-call detail; use audit(4) for configured audit events; use service-specific logs for application behavior. Each has distinct performance, privacy, and coverage properties.

If a process crashes, is killed by a system failure, or remains active, an accounting record may not exist. If the accounting file is on a full filesystem, read-only filesystem, or failed device, records can be incomplete. Verify the facility is enabled and the file can be written, but do not create test noise during an incident without marking it.

Build a timeline from several independent clocks and sources. Record time zone and clock synchronization state, command-accounting output, login records, system log timestamps, service logs, and relevant filesystem or network events. Accounting output alone should not be used to attribute intent or prove that a user personally typed a command.

Operational acceptance criteria

Accounting is ready when a test command produces a visible record, root-only access is enforced, persistence after reboot is verified, file growth is monitored, retention and rotation are tested, and investigators understand its gaps. Check that the configured file path on boot matches the path that operators query.

When collection is no longer needed, disable it intentionally, preserve records under the approved policy, and confirm the kernel facility is off. Retain a short runbook containing the exact path, enable/disable commands, test procedure, and contact for records access.

Related:

Sources: