Skip to main content

Module pressure

Module pressure 

Source
Expand description

Resource pressure, and what a healthy daemon does about it: shed new work, drain what is in flight.

The failure this exists for is disk. The file store writes until ENOSPC, and a checkpoint failure is a halting condition, so a full disk would otherwise stop the agent after the fact with nothing between “fine” and “dead”. Two thresholds give it a middle: below warn the operator is told; below shed the daemon stops admitting work — no new runs fired, webhooks answered 429 Retry-After, no new turns dispatched — while everything already running drains normally. An agent that finishes its current job but takes no more degrades; one that dies mid-checkpoint corrupts the next restart’s starting point.

Memory pressure (the cgroup’s memory.high, when armed) sheds through the same gate. Every admission point must consult the same verdict: a daemon that refuses to spawn a child at its soft limit while still accepting a webhook, firing a schedule and dispatching a turn has not shed anything.

Assessment is cached (~2s) and lock-free to read: the gates sit on hot paths and a statvfs per webhook would be its own kind of pressure.

Structs§

Pressure

Enums§

Level
How pressed the daemon is. Ordering matters: higher is worse.

Functions§

free_bytes
Free bytes available to unprivileged writes on path’s filesystem.
parse_bytes
Parse a human size: 256MB, 1.5GiB, 524288000. Decimal and binary prefixes both mean binary here — an operator writing 256MB for a threshold wants “about a quarter gig”, and the 4.8% difference is noise against a knob whose purpose is “not zero”.