Context
An audit warning means the evidence pipeline itself may be under pressure. Linux audit events can wait in a kernel backlog before auditd consumes them. If records are discarded, increasing capacity later does not recreate the missing evidence. First preserve the counters and timeline, then investigate why production exceeded consumption.
Before collecting details, identify the host, distribution, audit policy owner and log-retention requirements. Administrative read access is usually required. Audit records may contain sensitive paths and account information, so keep raw evidence in the approved restricted location. Do not disable auditing or clear counters as an exploratory troubleshooting step.
Separate current pressure from earlier loss
- Run
sudo auditctl -sand record its timestamp. Reviewpid,backlog,backlog_limit,lost,rate_limitand failure behavior. A daemon PID of zero needs immediate attention. The backlog is currently queued work; the lost field reports discarded records. Save a second sample after a short meaningful interval to determine whether loss is still increasing. - Review the daemon status and its recent messages using the distribution's supported read-only tools. Inspect free space and write health on the actual audit-log filesystem. A service can exist but process records too slowly because its output path is blocked or configured disk-space actions have triggered. Do not assume the largest directory elsewhere on the host is relevant.
- Inspect active rules with
sudo auditctl -land compare them with the approved policy. Look for a recent rule deployment or a high-frequency operation newly captured across a broad path. Review plugin or forwarding behavior where applicable. Remove or narrow a rule only after the audit owner confirms the evidence requirement, rather than treating every busy rule as expendable.
An illustrative misleading recovery
In an illustrative batch server, an unusually broad audit rule causes loss during a nightly import. By morning, the backlog is empty and auditd looks active. The cumulative lost counter remains higher than the previous baseline. Reporting the empty backlog as full recovery would omit an evidence gap that occurred during the import and could recur the following night.
| Observation | First question | Next action |
|---|---|---|
| Backlog high, lost stable | Is a temporary burst draining? | Compare timestamped samples |
| Lost counter increasing | Is consumption unable to keep up? | Inspect storage, rules and daemon state |
| Backlog zero, lost nonzero | When did loss occur? | Correlate prior baselines and workload |
| Daemon PID zero | Why is auditd absent? | Follow distribution recovery procedure |
Correct capacity with the policy owner
Possible corrections include restoring storage writes, repairing a blocked consumer, replacing an unintended rule or adjusting a supported backlog setting for a measured burst. Choose the demonstrated cause. Larger queues consume resources and can only defer a sustained producer-consumer imbalance; changing failure behavior can have host-availability consequences.
Rehearse the correction with an authorized representative workload in staging. In production, verify that current events reach the audit log, backlog drains and the lost counter stops increasing. Preserve the original loss interval in the incident record. Do not claim that a successful test proves completeness of previously discarded records.
Monitor the evidence pipeline
Alert on changes in lost records, persistent backlog, audit storage pressure and daemon health. Record normal workload periods, rule ownership and the escalation path for evidence gaps. Include the expected handling of immutable audit settings, because some changes require a planned reboot. Clouvenix Linux administration can help make audit health an explicit operating responsibility.