Memory and durable resource limits

What the limits mean

0.4.0 bounds native ingestion, detection, retries, storage and administration. It does not promise a whole-process RSS ceiling or zero allocation throughout the daemon. Zig allocation checks, SQLite’s separate heap and kernel/process resources have different accounting boundaries.

The old tracker-only model is not the native runtime’s durability contract. Critical receipts, active protection owners and unresolved enforcement intent are not evicted merely to make room for new traffic.

Admission before work

Startup builds a resource plan and refuses configurations that cannot fit their native memory or descriptor budgets. The default plan admits at most 64 enabled jails, eight file incarnations per jail and 4,096 live retry subjects across enabled jails. Rule programs also have explicit input and work limits.

Adding sources or native rules can change the admitted plan. A syntactically valid configuration can still fail runtime admission; inspect the reported cause rather than raising every limit without understanding the workload.

Durable state is part of the budget

SQLite stores complete record receipts, source checkpoints, retry state, policy, protection ownership, effect intent and confirmed history. Database pages and the SQLite heap are bounded separately from Zig-owned allocations. Retention can reclaim eligible history while required recovery anchors remain pinned.

flowchart LR
  A[Source record] --> B[Bounded admission]
  B --> C[Durable receipt and checkpoint]
  C --> D[Detection and policy]
  D --> E[Durable effect intent]
  E --> F[Dispatch and kernel readback]

Source acknowledgement and in-memory publication follow the relevant commit. Original event and receipt times survive retries and restart, so retry does not invent a fresh observation window or extend an existing deadline.

Exhaustion and recovery

When required storage fails, affected ingestion pauses and health becomes degraded. Existing protection is retained; the administrative surface remains available to report the cause. Capacity pressure must not silently discard unresolved effects or active owners.

Corrupt or incompatible state is refused at startup. Do not delete the database or its sidecars to suppress a failure. Repair access or restore coherent state, then verify ownership and source continuity before considering the daemon healthy. See upgrade and recovery guidance.

Measure the complete deployment

Use OS process metrics alongside fail2zig status and readiness. Include SQLite, source count, journalctl children, backend helpers, database size and descriptor use in a workload review. A parser microbenchmark cannot establish daemon memory, end-to-end throughput or latency under storage pressure.

0.4.0 release qualification supplies bounded-component and recovery evidence, not a new comparative performance benchmark. The tagged architecture defines the release’s resource boundary.