In this lesson, you will learn how to use process accounting logs to reconstruct a timeline of events after a system performance incident.
Understanding Process Accounting
When a system experiences a sudden spike in CPU or memory usage, your standard tools (like top or ps) only show you what is happening right now. To understand what happened five minutes ago—especially if those processes have already exited—we rely on Process Accounting.
Linux keeps a permanent record of every command executed on the system if the acct service is enabled. These records are stored in a binary format (usually in /var/account/pacct or /var/log/account/pacct). Because they store the exit status, CPU time consumed, and the user who invoked the command, they act as a "flight data recorder" for your shell sessions.
Reconstructing History with lastcomm
The most common way to view these logs is the lastcomm command. It reads the accounting file and presents a readable summary of executed commands.
If you are investigating why the system slowed down, you might run:
lastcomm --user username
This will output a list of commands executed by that user, showing the command name, the flag (e.g., S for superuser, F for fork without exec), and the duration the process held the CPU.
For example, if you see a line like this:
my_script root pts/0 0.02 secs
You can verify that my_script was indeed the process that consumed resources at a specific time. If you notice a spike in fork() calls or a specific utility running thousands of times, you have found your culprit.
Auditing vs. Accounting
While Process Accounting tracks the "what" and "how much" (resource usage), Auditing (often managed by the auditd daemon) tracks the "who" and "why" by logging specific system calls. For basic post-incident reconstruction, lastcomm provides the quickest overview of what processes were spawned during the performance degradation window, allowing you to match a timestamped incident report against actual process execution logs.
Key Takeaway: Process accounting allows you to look back in time to identify which processes consumed system resources even after they have finished executing.