ProcessKit API Reference
LimitVerdict Type
The post-run verdict for **one** resource-limit axis — did a cap this group carried actually **engage** while the tree ran? Read from `ProcessGroup.LimitEvidence()`; see that member for exactly when it becomes available. This answers a different question than `ProcessError.ResourceLimit`: that error is about **admission** — "could the cap you asked for even be applied?" This verdict is about what only the container itself can answer afterwards — "did a cap on this axis then actually fire?" A `Tripped` verdict is returned only on **authoritative kernel/OS evidence** recorded by the group's own container; exit codes and signals are never consulted, because a cap-driven kill and a self-inflicted crash can look identical from the outside, and inferring from them would manufacture exactly the false verdict this type exists to avoid.
Union cases
| Union case |
Description
|
Full Usage:
NotTripped
|
This cap did **not** engage. Either its counter is present and reads zero, or this axis was never capped on this group at all — both are the same honest "no"; neither is a fallback for missing evidence (that is `Unknown`). |
Full Usage:
Tripped
|
The kernel/OS recorded that this cap engaged: the tree was OOM-killed under its memory cap, denied a fork by its process cap, or throttled by its CPU quota. |
Full Usage:
Unknown
|
**No authoritative evidence is available**, so the answer is refused rather than guessed at. The containment mechanism keeps no post-mortem record for this axis at all (every axis on a Windows Job Object, or the POSIX process-group fallback — neither persists a "this cap fired" counter), or the specific counter file/key could not be read on this run (an older kernel, a controller without that accounting, a cgroup already gone). |
Instance members
| Instance member |
Description
|
Full Usage:
this.IsNotTripped
Returns: bool
|
|
Full Usage:
this.IsTripped
Returns: bool
|
|
Full Usage:
this.IsUnknown
Returns: bool
|
|