Peios Events Index

An event is a record that something happened: an access was checked, a service started, a package was installed, a descriptor was found corrupt. Events are produced by the component that observed the thing, and consumed by whatever is watching — usually eventd, sometimes a tool reading the stream directly.

This book enumerates every event Peios emits, with the fields each one carries. It is a lookup, not an explanation. Where an event's meaning needs the mechanism behind it, the page links to the manual that describes that mechanism.

1.1.1 Where the schemas come from #

Every event type and every field is defined in the evman catalogue: the .evman fragments each component installs in /usr/share/evman/ (PGSS §6.10). The catalogue is the definition, and most of this book is generated from it:

• §2 describes the groups, the sets of fields that travel together, such as subject.
• §3 to §15 have a page per event type, one chapter per root: the kernel's kacs, stratafs, lcs, kmes and ntfe (§3 to §7), then peinit, peipkg, eventd, authd, lpsd, timed, netd and trustd (§8 to §15).
• Appendix A lists every event type in one table, and Appendix B is the field index: every field, its type and values, and every event that carries it.

On a running system, evman <event-type> prints the same definition from the installed fragments (evman).

1.1.2 Two transports, not one #

Most events travel through KMES, the kernel message event stream: a per-CPU ring buffer that the kernel writes into and userspace reads from. Every KMES event is a binary header followed by a MessagePack payload (§1.2).

Two things in this book never travel through KMES:

• eventd's records about itself (§10) are catalogue events, but eventd writes them straight into its event store and they never touch KMES. They carry no sequence number and no emitter.* stamps.
• LCS watch records (§16) are not events at all, and are included because an operator looking for "what does Peios tell me" would otherwise miss them. They are binary records read from a key file descriptor: a notification mechanism, not an audit trail, with a format that has nothing in common with a KMES event.

1.1.3 What is not here #

This book does not cover logs or metrics. Both reach eventd by a different path, are stored in different tables, and are not events. The eventd manual covers them.

Nor does it cover the query language for reading events back. That is PSPU §3, with the operator-facing view in the eventd manual.

1.1.4 Checking generated catalogue pages #

The event, group and field-index pages are generated from .evman fragments by PKM's tools/gen-events-book.py. Edit the fragments rather than those pages. --check compares the generated pages without writing; omit it to regenerate. The PKM pre-push hook checks this output when kernel event fragments or the generator change.

The generator reads kernel fragments from its own checkout and userspace fragments from sibling component directories such as peinit/ and eventd/. Keep the component fragments present when regenerating the complete index: an absent userspace fragment is reported and omitted from the output. For the same reason --check skips, naming the missing fragments, unless every userspace fragment is present.

Documentation defaults to a sibling learn/. For a separate worktree:

PKM_LEARN_ROOT=/path/to/docs-worktree python3 tools/gen-events-book.py --check

An invalid explicit path fails. Missing or stale generated pages in the selected documentation checkout fail --check, including a missing events book. A standalone PKM checkout without a documentation companion skips the check. The same path override applies to the pre-push check.

Every KMES event is a packed binary header followed immediately by its MessagePack payload, delivered as one contiguous byte sequence with no padding anywhere.

The emitter supplies only two things: the event type and the payload. Everything else in the header is stamped by KMES itself, which is what makes the identity fields trustworthy — an emitter cannot forge them.

1.2.1 Fields KMES stamps #

A consumer that exposes header values by name exposes them under these field paths (PGSS §6.4). They are fields like any other, defined in the catalogue and listed in the field index under event and emitter, but they live in the header, and no payload repeats them.

emitter.class is set by the kernel, never by the emitter. A record whose type names a kernel root but whose class is 0 was written by a program, whatever its type says. The class is the path, not the type's root: StrataFS records are written through KACS and carry class 2.

The identity stamps matter for reading this book: several events carry no caller in their payload at all, because the envelope already names one. StrataFS copy-up records are the clearest case — nothing in the payload names a token, and the caller is recovered from the header. A record written outside task context has zero GUIDs, and emitter.stamp-failure in its payload says why.

event_size, header_size and type_len are structural, computed by KMES during construction, and are not exposed as fields.

1.2.2 Layout #

All fields before the event type string sit at fixed offsets. The type string begins at offset 77, with its u16 length at offset 75, so the header is exactly 77 + type_len bytes. The payload runs from header_size to event_size, and the next event begins at event_size from the start of the current one.

All multi-byte header integers are little-endian. The identity GUIDs are opaque 16-byte values.

The full field-by-field layout is normative in PSPK §2, the KMES event stream specification. This summary is enough to walk a stream; it is not enough to implement one.

1.2.3 Ordering #

event.time is captured before event.sequence is assigned, so two events with the same time on the same CPU are ordered by sequence. event.cpu and event.sequence together identify a record within a boot, and with event.boot.guid across boots.

Across CPUs there is no global order. Two events on different CPUs with close timestamps may have been observed in either order.

Every KMES payload in this book is a MessagePack map with UTF-8 string keys. What may appear in it, and what each value means, is defined by the evman catalogue; the rules below are how the catalogue's definitions become bytes (PGSS §6.4 and §6.5).

1.3.1 The catalogue is the definition #

Every event type and every field is defined once, in a .evman fragment installed in /usr/share/evman/ (PGSS §6.10). An emitter writes no field the catalogue does not define, and this book's event pages and field index are generated from the same fragments.

To read a definition on a running system, use evman: evman kacs.audit.access.checked prints an event type, evman subject.token.sid a field, and evman kacs.audit everything beneath a prefix.

1.3.2 Names #

An event type reads as who wrote it, what it is about, and what happened: <root>.<noun>[.<noun>…].<verb>, all lowercase kebab-case, ending in a past-tense verb. kacs.audit.access.checked and stratafs.file.copied-up are event types (PGSS §6.3).

A field is named for the part it plays, then what it is, then which property of it the value is: subject.token.sid, object.file.path, outcome.success (PGSS §6.4).

1.3.3 A path is nested maps #

A field's path is the chain of keys that leads to its value. Each segment is one map:

subject.token.sid   is   { "subject": { "token": { "sid": <bin> } } }

No key contains a .. A key "subject.token.sid" at the top level of a payload is a different field from subject.token.sid, and not one any consumer looks for.

A path is either a value or a map, never both. access.granted is a value, so nothing is ever defined beneath it, and its variants are its siblings: access.granted-staged, not access.granted.staged.

1.3.4 Absent, not nil #

A field with no value is omitted: the key is not written. An emitter never writes nil, an empty string or zero to mean "none". A field whose event page says when outcome.success == false is simply not in a record that succeeded.

1.3.5 Value representations #

A field's type, given on its event page and in the field index, names its wire form.

A type ending [] is an array of that type. Arrays that describe the same items are parallel: subject.token.group-attributes[i] describes subject.token.groups[i].

Binary SIDs, GUIDs and ACEs are carried as bytes rather than as text because they are compared as bytes. A principal is carried as its SID only, never with its name beside it: a name is resolved when the record is read.

1.3.6 Enumerations are kebab-case words #

An enumeration is a string naming the value — wrong-type, not 2. Each one's values are listed in its definition, or by the event that carries it, together with whether the set is closed. A value of an open enumeration that a consumer does not recognise is a value, not an error.

A uint.enum is used only where the numbers are fixed elsewhere — an impersonation level, an address family, emitter.class — and a consumer shows it by name.

1.3.7 Errors are negative errno #

outcome.errno is the negative error number the operation returned: -13 for EACCES. It is omitted on success. Why an action failed, as a word, is outcome.reason; whether it succeeded at all is outcome.success (PGSS §6.6).

Four rules govern every consumer of this stream.

1.4.1 Ignore unknown keys #

Future versions may add fields to an event without changing the existing ones. A consumer that processes the keys it knows and ignores the rest keeps working across upgrades. A consumer that rejects unrecognised keys breaks on the first addition.

1.4.2 Read absence by the field's presence #

A key that is absent means the emitter had no value for it (§1.3) — nothing more. Each event page says when each field is present: required, optional, or when a condition on another field holds. Read absence against that, not as a signal of its own. A field that is optional today may become always present later.

1.4.3 Delivery is best-effort #

KMES is a ring buffer. The kernel writes; keeping up is the subscriber's problem.

• A subscriber that falls behind loses events. eventd notices and records an eventd.events.lost, which is how a gap becomes visible rather than silent.
• There is no replay. An event missed is gone. Nothing can ask for it back.
• Buffers are per-subscriber. One slow reader does not affect another.
• Order is per-subscriber, not global.

For durable audit, read events from eventd's stores rather than from KMES directly. eventd drains its subscription continuously and persists what it reads; from that point the store is the record, not the ring.

1.4.4 Events are not authenticated #

Events are trusted because they came through KMES, not because they are signed. Nothing in an event carries a signature. What the kernel vouches for is the header: emitter.class says which path wrote a record, and a program can write any event type it likes with class 0 (§1.2).

Cryptographic non-repudiation is a userspace concern applied after events leave the kernel. If a deployment needs it, it is added on the far side of eventd, not here.

1.4.5 Versioning #

Event types are not versioned by a field. Some changes to the catalogue are additive and can arrive in any update: a new event type, a new field, a new value of an open enumeration. A consumer that ignores what it does not know, and treats an unknown value of an open enumeration as a value, keeps working across them.

Renaming an event type or a field, moving a field to another path, changing a field's type, or adding a value to a closed enumeration is not additive. Each needs a new version of the event vocabulary, because every query and descriptor written against the old shape stops matching (PGSS §6.11).

• Group: caller
• Defined in: lcs.evman

The identity LCS records on an audited operation. A deliberate subset of subject — the token's durable GUIDs ride in the event header, and the group SIDs and PIP state that KACS records are absent here.

That absence is a gap rather than a design. Access to a registry key is granted through a group as often as to a user SID directly, so an LCS record cannot answer "which membership let this through" where the equivalent KACS record can. The two subsystems reached the bound on what to serialise independently and landed in different places.

2.1.1 Fields #

2.1.2 Carried by #

• lcs.audit.backup.ended
• lcs.audit.backup.started
• lcs.audit.key.created
• lcs.audit.key.deleted
• lcs.audit.key.descriptor.changed
• lcs.audit.key.hidden
• lcs.audit.key.opened
• lcs.audit.key.tombstoned
• lcs.audit.restore.ended
• lcs.audit.restore.started
• lcs.audit.transaction.committed
• lcs.audit.value.deleted
• lcs.audit.value.set

Generated from lcs.evman by pkm/tools/gen-events-book.py. Edit the fragment, not this page.

• Group: subject
• Defined in: kernel.evman

The security context an operation ran under, carried by every KACS event that has a causing principal. Three components: the effective token, the process it ran in, and the PIP state in force.

The process is the emitter's, under emitter.process, because a kernel access check runs in the caller's own context: the process that acted is the process that wrote the record.

The token and the process are different principals when impersonating. The token is the client's and the process is the server's, so reading the pair as one identity will attribute a client's work to a server or the reverse. subject.token.type is what tells you they have diverged.

The durable GUIDs are not repeated here. emitter.token.guid, emitter.true-token.guid and emitter.process.guid ride in the event header, so they are present on every event whether or not this group is.

Privileges, claims, the restricted-SID list, confinement state and the default DACL are all deliberately absent. Each is unbounded and an event embedding them could grow without limit. Code needing full token state queries the token directly while it still exists; this group is for correlation, not reconstruction.

2.2.1 Fields #

2.2.2 Carried by #

• kacs.audit.access.checked
• kacs.audit.descriptor.changed
• kacs.audit.handle.used
• kacs.audit.privilege.used
• kacs.caap.policy.changed
• kacs.caap.sacl.skipped
• kacs.caap.staging.diverged
• kacs.descriptor.rejected
• kacs.impersonation.reverted
• kacs.impersonation.started
• kacs.mount.policy.changed

Generated from kernel.evman by pkm/tools/gen-events-book.py. Edit the fragment, not this page.

• Event type: kacs.audit.access.checked
• Defined in: kacs.evman
• Tier: essential
• Gating: a matching SACL audit ACE, or the token's audit policy; on the AccessCheck syscall a SACL record also needs the caller to hold SeAuditPrivilege, enabled
• Cardinality: once per matching audit ACE, not once per access

The record that an access check completed, and what it decided. The most common event on the system, and the one most investigations start from.

A daemon's own checks need SeAuditPrivilege. A userspace component that guards its objects with the AccessCheck syscall supplies the descriptor itself, SACL included. Its records are written only if the calling process holds SeAuditPrivilege, enabled, on its effective token, as Windows asks of AccessCheckAndAuditAlarm; without it the check is answered and its SACL records are silently withheld. The privilege is the caller's, not the checked client's. Records the checked token's own audit policy forces are written either way.

It fires against every kind of object KACS protects — files, processes, tokens, sockets and SysV IPC objects — which is why object.kind is required. A process opening another process, or a token adjusting another token, puts an actor and an object of the same kind in one record, so the subject. and object. fields are never interchangeable.

It is silent by default. Nothing is recorded unless an audit ACE in the object's SACL matches, or the calling token's audit policy forces it. An object with no SACL produces no record on any outcome, including denials.

One access can produce several records. The event is per matching audit ACE, so an access matching three ACEs produces three records differing only in trigger.ace.

3.1.1 Fields #

Every record also carries the header fields of the envelope, which no payload repeats.

Generated from kacs.evman by pkm/tools/gen-events-book.py. Edit the fragment, not this page.

• Event type: kacs.audit.descriptor.changed
• Defined in: kacs.evman
• Tier: essential
• Gating: a change that includes the SACL, always; any other change when the rights it needed overlap the alarm mask on the handle it was made through
• Cardinality: once per authorised change

The record that a caller changed, or was authorised to change and failed to change, the security descriptor of a file, a token, a process or a System V IPC object. Registry keys have their own record of the same shape, lcs.audit.key.descriptor.changed.

A change to a SACL is always recorded, whatever the old or new descriptor says. Changing a SACL needs ACCESS_SYSTEM_SECURITY, which needs SeSecurityPrivilege; it is rare; and removing one is how an intruder stops being watched. Before this record existed a file's SACL could be removed in silence, because the only audit of a descriptor change was evaluated against the new SACL, which then had nothing in it.

Any other change — the owner, the group, the DACL, the integrity label — is recorded when the rights it needed overlap the alarm mask on the handle it was made through: the rule kacs.audit.handle.used follows. Only a file handle carries such a mask, so for a token, a process or an IPC object only a SACL change is recorded.

The descriptors themselves are not carried, only their SHA-256 digests, lengths and owners. Equal digests mean the change rewrote the descriptor without altering it.

3.2.1 Fields #

Every record also carries the header fields of the envelope, which no payload repeats.

Generated from kacs.evman by pkm/tools/gen-events-book.py. Edit the fragment, not this page.

• Event type: kacs.audit.handle.used
• Defined in: kacs.evman
• Tier: essential
• Gating: the operation's required access overlaps the alarm mask cached on the handle
• Cardinality: once per operation on the handle

The record of what was done with a handle after it was opened. Where kacs.audit.access.checked records the decision to open something, this records each subsequent use of it.

The mask is configured by SYSTEM_ALARM* ACEs at the access check that opened the handle, and the record is produced afterwards by whatever enforcement point handles the operation. FACS, for file handles, is the only such point today.

The subject is re-read on every operation. A handle outlives the token that opened it, so a process that starts or stops impersonating keeps its handles and every later operation is recorded under the token current at that moment. An investigation assuming the open-time identity will attribute later operations to the wrong principal.

Three masks appear together and are easy to confuse. Read as a sentence: the operation needed access.requested, of which access.matched triggered the audit, against a handle opened with access.granted, and it succeeded or did not.

3.3.1 Fields #

Every record also carries the header fields of the envelope, which no payload repeats.

Generated from kacs.evman by pkm/tools/gen-events-book.py. Edit the fragment, not this page.

• Event type: kacs.audit.privilege.used
• Defined in: kacs.evman
• Tier: essential
• Gating: the token's audit policy, success and failure flavours independently; at a capability or volume gate, also the first use of that gate by the process under its current token, and never a CAP_OPT_NOAUDIT check
• Cardinality: once per privilege that contributed access; at a gate, once per process, token and gate

The record that a privilege was spent. Purely token-policy driven — no SACL is involved, so there is no trigger to record. operation.name says where it was spent, and the rest of the record follows from it.

access-check is a privilege that contributed access to an access check, with whether that contribution survived. Success there means the privilege worked, not that it fired. This is the field most often misread. A false outcome is not a failed attempt to use a privilege; it is a privilege that fired and was then overridden by a confinement, a CAAP rule, or PIP non-dominance — usually the more interesting of the two records, because it shows a boundary holding. MAXIMUM_ALLOWED requests produce nothing here. Privilege-use auditing short-circuits on them, even though SACL auditing was deliberately changed not to — a probing enumerator therefore trips one and slips the other.

linux-cap is a privilege that satisfied a Linux capability check: KACS answers every capability check with a privilege, and linux.cap names the check. volume-mount is a privilege that satisfied the volume-management gate the mount paths ask instead of CAP_SYS_ADMIN. Each is recorded once per process, token and gate, not once per check: a TCB process makes thousands of CAP_SYS_ADMIN checks a second, and the first answers who used the privilege and for what. The set starts again when the process acts under another token. Only successful uses are recorded, and only those of a user process's own checks: a probe with CAP_OPT_NOAUDIT, a kernel thread's check and a check against another process's credentials record nothing. The record is written as the process returns to user space, so it follows the system call that spent the privilege.

A token can carry either audit policy flavour, both, or neither, and each governs its own outcome independently. The boot SYSTEM token carries PRIVILEGE_USE_SUCCESS, so on a stock machine the records come from SYSTEM and the services that inherit its token.

3.4.1 Fields #

Every record also carries the header fields of the envelope, which no payload repeats.

Generated from kacs.evman by pkm/tools/gen-events-book.py. Edit the fragment, not this page.

• Event type: kacs.caap.policy.changed
• Defined in: kacs.evman
• Tier: essential
• Gating: none — every change a caller holding SeTcbPrivilege makes is recorded
• Cardinality: once per kacs_set_caap call that passed the privilege gate

The record that a central access policy was installed, replaced or removed. A policy decides access to every object whose SACL names it, alongside that object's own DACL, so one change here can widen or narrow access across the whole system without touching any object.

Only a caller holding SeTcbPrivilege, enabled, may change a policy; a call refused for want of it is not recorded. A call that passed the gate is recorded whether or not it applied: a malformed specification leaves the old policy in force and the record says so.

The record names the policy, not its rules. Compare two records' effects by the access records that follow them.

3.5.1 Fields #

Every record also carries the header fields of the envelope, which no payload repeats.

Generated from kacs.evman by pkm/tools/gen-events-book.py. Edit the fragment, not this page.

• Event type: kacs.caap.sacl.skipped
• Defined in: kacs.evman
• Tier: standard
• Gating: an access check that evaluates a central access policy rule whose SACL cannot be used
• Cardinality: once per rule whose SACL failed

The record that a central access policy rule's SACL could not be parsed or evaluated, so the audit it asked for was skipped. The access decision is unaffected — a rule's SACL only adds audit records — but the records that rule should have produced for this access do not exist.

This is the only evidence of the missing audit. An administrator who put an audit ACE in a policy rule expects records from every object the policy covers; while the rule's SACL is broken, none arrive, and nothing else says so.

A failure in a rule's staged SACL (caap.phase is staged-sacl) is recorded too. It changes nothing in force, and is the warning that promoting the staged policy would install a SACL that does not work.

3.6.1 Fields #

Every record also carries the header fields of the envelope, which no payload repeats.

Generated from kacs.evman by pkm/tools/gen-events-book.py. Edit the fragment, not this page.

• Event type: kacs.caap.staging.diverged
• Defined in: kacs.evman
• Tier: standard
• Gating: a staged central access policy applies to the object, and its result differs from the effective one
• Cardinality: once per access check

The record that a staged central access policy would have decided an access differently from the policy in force. The access itself is decided by the effective policy alone; this records what promoting the staged one would change, for this subject and this object.

It is the event to watch while trialling a policy: stage it, let the system run, and read these records to see who would gain or lose access before anyone does. It is silent unless a staged policy exists, so on most systems it never fires.

The difference is not always in the grant. Staged and effective evaluation also differ when the per-object results of an object-type check differ, or when the audit records the two would produce differ, so a record can carry equal access.granted and access.granted-staged.

3.7.1 Fields #

Every record also carries the header fields of the envelope, which no payload repeats.

Generated from kacs.evman by pkm/tools/gen-events-book.py. Edit the fragment, not this page.

• Event type: kacs.config.value.rejected
• Defined in: kacs.evman
• Tier: essential
• Gating: none — every rejected table is recorded
• Cardinality: once per rejected read of the key

The record that KACS read one of its registry-held tables, rejected it, and carried on with what it had. Today that is the port reservation table under Machine\System\Network\TcpIp\PortReservations, read whenever the key changes.

The table is validated whole and is reject-or-keep, never merge: one bad value refuses all of them, and whatever was in force before — the last good table from the registry, or the compiled-in fallback — stays in force. That makes this the only place the divergence is visible: the registry shows what an administrator wrote, and this record shows that KACS is not using it. The same reject-or-keep rule as kmes.config.value.rejected and lcs.config.value.rejected, for a table rather than a single value.

3.8.1 Fields #

Every record also carries the header fields of the envelope, which no payload repeats.

Generated from kacs.evman by pkm/tools/gen-events-book.py. Edit the fragment, not this page.

• Event type: kacs.descriptor.rejected
• Defined in: kacs.evman
• Tier: standard
• Gating: none — every unreadable stored descriptor is recorded
• Cardinality: one record per occurrence

The record that KACS read an object's stored security descriptor, found it corrupt, and refused to use it. The object is then treated as having a descriptor nobody can satisfy, so every access to it is denied until the descriptor is replaced by someone allowed to write one.

This is often the only explanation for a sudden, universal denial. A file that everyone could open and nobody now can, with no change to its descriptor anyone remembers making, is usually this: the stored bytes no longer parse, whether from disk corruption, a tool writing the extended attribute directly, or an interrupted write.

KACS records the event once per descriptor read, when the object's descriptor cache is filled, not on every denied access that follows. The subject is whoever's access made KACS read the descriptor: the first to touch the file after it was cached, not whoever corrupted it.

3.9.1 Fields #

Every record also carries the header fields of the envelope, which no payload repeats.

Generated from kacs.evman by pkm/tools/gen-events-book.py. Edit the fragment, not this page.

• Event type: kacs.impersonation.reverted
• Defined in: kacs.evman
• Tier: verbose
• Gating: none — every impersonation that ends is recorded
• Cardinality: once per impersonation ended

The record that a thread stopped impersonating and acts as its own token again. The subject is the thread's token after the revert; the object is the impersonation token it gave up, which a kacs.impersonation.started record named.

Verbose, because it is bookkeeping. An API that impersonates per request reverts once per request too, and the start already carries the security decision.

Not every end is recorded. A thread that exits while impersonating writes nothing: its credentials are released where no record can be built. And installing a new primary token does not end an impersonation — the impersonation is put back over the new token — so it writes nothing either.

3.10.1 Fields #

Every record also carries the header fields of the envelope, which no payload repeats.

Generated from kacs.evman by pkm/tools/gen-events-book.py. Edit the fragment, not this page.

• Event type: kacs.impersonation.started
• Defined in: kacs.evman
• Tier: standard
• Gating: none — every impersonation attempt that names a client token is recorded
• Cardinality: once per attempt

The record that a thread took on, or tried to take on, a client's identity by impersonating its token. The subject is the server — the token that acted, as it stood before the switch — and the object is the client token. Successes and refusals are both recorded.

Impersonation is per thread, so emitter.thread.tid names the thread that changed identity, not emitter.process.pid. Records the thread writes afterwards carry the client's token in their header, until a kacs.impersonation.reverted record ends it.

The level can be lowered without the attempt failing. object.token.impersonation is the level the client token offered, and object.token.impersonation-permitted the level KACS let the server have. Where the second is lower — the server lacked SeImpersonatePrivilege for a different user, or the client's integrity was above the server's — the impersonation succeeded at Identification, which can query the client's identity but not act as it.

The GUID is the installed token's. A lowered level installs a new token, so object.token.guid and object.token.id on a success are that token's, and they match the emitter.token.guid of the thread's later records. Exactly when the level was lowered they differ from the GUID of the token the client handed over.

3.11.1 Fields #

Every record also carries the header fields of the envelope, which no payload repeats.

Generated from kacs.evman by pkm/tools/gen-events-book.py. Edit the fragment, not this page.

• Event type: kacs.mount.policy.changed
• Defined in: kacs.evman
• Tier: essential
• Gating: none — every change a caller admitted by the volume-management gate makes is recorded
• Cardinality: once per change

The record that a filesystem's KACS mount policy was set: what happens to an object on it that has no stored descriptor. unmanaged turns access control off for the whole filesystem; deny-missing refuses such objects; the two synthesize policies build a descriptor from the parent and the template the caller supplies.

Setting a policy needs SeManageVolumePrivilege or SeTcbPrivilege. Every other refusal comes before that check, so a record is always of a change made.

The record does not carry the template. A synthesising policy's template descriptor decides what every unlabelled object on the filesystem grants; read it back with kacs_get_mount_policy.

3.12.1 Fields #

Every record also carries the header fields of the envelope, which no payload repeats.

Generated from kacs.evman by pkm/tools/gen-events-book.py. Edit the fragment, not this page.

• Event type: kacs.session.destroyed
• Defined in: kacs.evman
• Tier: essential
• Gating: none — every logon session that ends is recorded
• Cardinality: one record per occurrence

The record that a logon session ended because its last token went away. KACS destroys a session once no token refers to it, or once the only tokens left are its own linked elevated and filtered pair with nothing else holding them, and writes this record as it does.

A session that never acquired a token ends another way: a holder of SeTcbPrivilege destroys it explicitly with kacs_destroy_empty_logon_session, and the same record is written.

A session whose authentication package name is not valid UTF-8 produces no record. KACS cannot encode the name and skips the event rather than write it, and the session is destroyed regardless.

The record follows the teardown, written by a kernel worker. A session usually ends when a freed credential drops its last token, at a point where the record cannot be built, so KACS queues it and a kernel work item writes it moments later. Its header therefore names that kernel worker rather than the process whose exit or revert ended the session, and it can arrive after records that process wrote later.

3.13.1 Fields #

Every record also carries the header fields of the envelope, which no payload repeats.

Generated from kacs.evman by pkm/tools/gen-events-book.py. Edit the fragment, not this page.

• Event type: kacs.signature.crypto.failed
• Defined in: kacs.evman
• Tier: essential
• Gating: none — recorded whenever the signature machinery cannot run
• Cardinality: one record per occurrence

The record that the machinery for verifying signed executables cannot run. From then on every signed executable is refused: a signature that cannot be verified fails the exec rather than passing as unsigned.

Recorded at boot when the probe for the ML-DSA-65 transform fails. KACS cannot refuse to start over it — a security module that fails to initialise boots with no protection at all, which is worse — so it reports instead, and the refusal happens at each exec. Without this record, the condition would show only as every process running without an integrity label.

3.14.1 Fields #

Every record also carries the header fields of the envelope, which no payload repeats.

Generated from kacs.evman by pkm/tools/gen-events-book.py. Edit the fragment, not this page.

• Event type: stratafs.file.copied-up
• Defined in: stratafs.evman
• Tier: standard
• Gating: none — every copy-up is recorded
• Cardinality: one record per occurrence

The record that StrataFS materialised an object into a writable stratum, successful or not. Copy-up is how a layered mount turns a read-only object into a writable one, so this is the record of a file coming into existence in a place it did not previously exist.

The record is written through KACS, so its emitter.class is kacs.

There is no subject in the payload, and that is not an omission. Copy-up preserves the source object's descriptor, so the resulting file records nothing about who caused it to exist. The actor is identified by the header instead: copy-up runs in the caller's own context, so emitter.token.guid and emitter.process.guid are the caller's.

That identification is currently weaker than it looks. The header carries GUIDs and nothing in the stream binds a GUID to a SID, an image or a process name, so an operator reading these records can group them by actor but cannot say who the actor was.

ENOTDIR from a failed parent materialisation surfaces here, in outcome.errno, rather than as a refusal record. Searching stratafs.mutation.refused for it finds nothing; the record exists under this type with every field present.

4.1.1 Fields #

Every record also carries the header fields of the envelope, which no payload repeats.

Generated from stratafs.evman by pkm/tools/gen-events-book.py. Edit the fragment, not this page.

• Event type: stratafs.mutation.refused
• Defined in: stratafs.evman
• Tier: standard
• Gating: none — every arrangement refusal is recorded
• Cardinality: one record per occurrence

The record that a mutation was refused because of how the mount is arranged, rather than because of an access check. Software writing where it cannot, or an arrangement that does not admit an operation someone expected — a mismatch between intent and configuration that is otherwise visible only as an error returned to a caller who may discard it.

The record is written through KACS, so its emitter.class is kacs.

The refusals that count are one explicit list: EROFS, EXDEV, ENOTDIR, EISDIR, ENOTEMPTY, EEXIST and EINVAL. Call sites cover every mutating path.

EACCES is deliberately absent. A refusal produced by an access check is recorded by the mechanism that performed it, so StrataFS does not duplicate it. Looking here for a permission denial finds nothing — look at kacs.audit.access.checked.

There is one exception, and it is deliberate. A refused deferred deletion is recorded on any non-zero result, including one refused by an access check, because by the time a deferred deletion fails there is nobody left to receive the error. Rollbacks arrive under this type with the same flag set: a create or link whose outer bookkeeping failed and whose lower object could not be removed again, and a failed publication rollback after a copy-up.

Resolution, revalidation and enumeration record nothing at all. They happen on every path operation, reveal nothing the resulting access check does not, and recording them would produce volume out of all proportion to their significance.

4.2.1 Fields #

Every record also carries the header fields of the envelope, which no payload repeats.

Generated from stratafs.evman by pkm/tools/gen-events-book.py. Edit the fragment, not this page.

• Event type: lcs.audit.backup.ended
• Defined in: lcs.evman
• Tier: essential
• Gating: none — audited unconditionally
• Cardinality: one record per occurrence

The record that a registry subtree backup finished, successfully or otherwise. Pairs with lcs.audit.backup.started on the same key.

Emission failure here does not affect the result, which has already been determined by the time this is written.

5.1.1 Fields #

Every record also carries the header fields of the envelope, which no payload repeats.

Generated from lcs.evman by pkm/tools/gen-events-book.py. Edit the fragment, not this page.

• Event type: lcs.audit.backup.started
• Defined in: lcs.evman
• Tier: essential
• Gating: none — audited unconditionally
• Cardinality: one record per occurrence

The record that a registry subtree backup began, emitted before any data is read. Backup is a privilege-gated bulk operation that bypasses per-key access checks entirely, so this trail is the only evidence it happened at all — which is why it is audited whatever the target key's SACL says.

The start record exists so that an operation dying partway still leaves evidence that it began. A start with no matching end is itself the finding.

Emission failure fails the operation with EIO, unlike every other LCS event: an unrecorded bulk read of the configuration store is not permitted to proceed.

5.2.1 Fields #

Every record also carries the header fields of the envelope, which no payload repeats.

Generated from lcs.evman by pkm/tools/gen-events-book.py. Edit the fragment, not this page.

• Event type: lcs.audit.key.created
• Defined in: lcs.evman
• Tier: essential
• Gating: a matching SACL audit ACE on the parent key, for KEY_CREATE_SUB_KEY
• Cardinality: once per key created

The record that a registry key was created. Creating a key checks only KEY_CREATE_SUB_KEY on its parent, so the parent's SACL decides, by the rule lcs.audit.key.opened applies to an open: a success audit ACE on the parent that matches the caller. No handle exists yet to carry an alarm mask.

Only a key that was made is recorded. A create that found the key already there and opened it instead writes nothing here; it is an open, and lcs.audit.key.opened records it if the key's own SACL asks. The record is written once the key exists, so a create whose handle then fails to reach the caller is still recorded, because the key was still made. A transacted create is recorded when staged.

5.3.1 Fields #

Every record also carries the header fields of the envelope, which no payload repeats.

Generated from lcs.evman by pkm/tools/gen-events-book.py. Edit the fragment, not this page.

• Event type: lcs.audit.key.deleted
• Defined in: lcs.evman
• Tier: essential
• Gating: DELETE overlaps the alarm mask cached on the key handle
• Cardinality: once per delete through a handle whose mask covers it

The record that a registry key was deleted from a layer through its own handle, or that an attempt failed. The key named is the one deleted, the handle's key, by GUID and full path.

Deleting a layer's metadata key, Machine\System\Registry\Layers\<Name>, deletes the layer itself; the record then also names the layer.

5.4.1 Fields #

Every record also carries the header fields of the envelope, which no payload repeats.

Generated from lcs.evman by pkm/tools/gen-events-book.py. Edit the fragment, not this page.

• Event type: lcs.audit.key.descriptor.changed
• Defined in: lcs.evman
• Tier: essential
• Gating: always when the change includes the SACL; otherwise WRITE_DAC or WRITE_OWNER overlaps the alarm mask cached on the key handle
• Cardinality: once per descriptor change it covers

The record that a registry key's security descriptor was changed through a key handle, or that an attempt failed.

A change to the SACL is always recorded, whatever the handle's mask. It takes ACCESS_SYSTEM_SECURITY, which only SeSecurityPrivilege grants, such changes are rare, and removing a SACL is exactly how someone hides what follows. It is recorded once the handle's own access check admits it: a caller whose handle lacks ACCESS_SYSTEM_SECURITY is refused before any record, so asking for a SACL change cannot be used to write records. Owner, group and DACL changes follow the handle's mask, as writes do.

Both descriptors are recorded by length, SHA-256 digest and owner, never in full. Whether the SACL was part of the change is object.sd.components.

5.5.1 Fields #

Every record also carries the header fields of the envelope, which no payload repeats.

Generated from lcs.evman by pkm/tools/gen-events-book.py. Edit the fragment, not this page.

• Event type: lcs.audit.key.hidden
• Defined in: lcs.evman
• Tier: essential
• Gating: DELETE overlaps the alarm mask cached on the key handle
• Cardinality: once per hide through a handle whose mask covers it

The record that a registry key was hidden in a layer through its own handle, or that an attempt failed. Hiding writes a marker that masks the key in every lower layer without deleting it there, so to every reader the key is gone; it is gated on DELETE, as deleting is.

5.6.1 Fields #

Every record also carries the header fields of the envelope, which no payload repeats.

Generated from lcs.evman by pkm/tools/gen-events-book.py. Edit the fragment, not this page.

• Event type: lcs.audit.key.opened
• Defined in: lcs.evman
• Tier: essential
• Gating: a matching SACL audit ACE on the key
• Cardinality: once per matching open

The record that a registry key was opened and what access the open received. SACL evaluation follows the KACS AccessCheck algorithm, with the SACL evaluated alongside the DACL rather than separately.

A request of MAXIMUM_ALLOWED alone records nothing. It maps to a desired mask of zero, and the SACL walk tests each audit ACE's mask against that mask, so no ACE matches. The one request shape that asks for everything is the one shape that produces no record — a real hole for anyone auditing key opens, and the same defect KACS's own SACL walk was changed to close.

Emission failure is handled in two halves. If a valid payload cannot be constructed, the open fails with EIO and no key descriptor is published — the audit is a precondition of the access. If a valid payload cannot be retained by KMES, the decision and the descriptor stand, and the loss is accounted as a gap in the stream rather than as a failed open.

5.7.1 Fields #

Every record also carries the header fields of the envelope, which no payload repeats.

Generated from lcs.evman by pkm/tools/gen-events-book.py. Edit the fragment, not this page.

• Event type: lcs.audit.key.tombstoned
• Defined in: lcs.evman
• Tier: essential
• Gating: KEY_SET_VALUE overlaps the alarm mask cached on the key handle
• Cardinality: once per blanket tombstone change through a handle whose mask covers it

The record that a key's blanket tombstone was set or cleared in a layer, or that an attempt failed. A blanket tombstone hides every value lower layers hold for the key at once, so setting one is a bulk value change and is gated on KEY_SET_VALUE, as value writes are.

5.8.1 Fields #

Every record also carries the header fields of the envelope, which no payload repeats.

Generated from lcs.evman by pkm/tools/gen-events-book.py. Edit the fragment, not this page.

• Event type: lcs.audit.restore.ended
• Defined in: lcs.evman
• Tier: essential
• Gating: none — audited unconditionally
• Cardinality: one record per occurrence

The record that a registry subtree restore finished, successfully or otherwise. Pairs with lcs.audit.restore.started on the same key.

5.9.1 Fields #

Every record also carries the header fields of the envelope, which no payload repeats.

Generated from lcs.evman by pkm/tools/gen-events-book.py. Edit the fragment, not this page.

• Event type: lcs.audit.restore.started
• Defined in: lcs.evman
• Tier: essential
• Gating: none — audited unconditionally
• Cardinality: one record per occurrence

The record that a registry subtree restore began, emitted before any state is modified. As with backup, this is a privilege-gated bulk operation that bypasses per-key access checks, and is audited regardless of the target's SACL.

A restore rewrites configuration wholesale, so a start with no matching end means the store may be in a partially rewritten state.

Emission failure fails the operation with EIO.

5.10.1 Fields #

Every record also carries the header fields of the envelope, which no payload repeats.

Generated from lcs.evman by pkm/tools/gen-events-book.py. Edit the fragment, not this page.

• Event type: lcs.audit.transaction.committed
• Defined in: lcs.evman
• Tier: essential
• Gating: the transaction staged at least one recorded write
• Cardinality: once per transaction that staged a recorded write

The record of how a registry transaction ended, written for a transaction that staged at least one write some other record covers. Transacted writes are recorded when they are staged; this says whether they took effect, joined to them on transaction.id.

It is written once, at the end: when REG_IOC_COMMIT leaves the transaction committed or otherwise finished, when it times out, or when its fd is closed without a commit. A commit that fails and leaves the transaction open writes nothing yet.

A commit that timed out may have taken effect. The commit was sent and not answered; transaction.commit-outstanding true says so, and the source may have applied it before the reply was lost.

The subject depends on how it ended. On REG_IOC_COMMIT it is the subject who committed, not who staged the writes. A transaction that ended by timeout or by its fd closing has nobody acting, and names the subject that staged its first recorded write.

5.11.1 Fields #

Every record also carries the header fields of the envelope, which no payload repeats.

Generated from lcs.evman by pkm/tools/gen-events-book.py. Edit the fragment, not this page.

• Event type: lcs.audit.value.deleted
• Defined in: lcs.evman
• Tier: essential
• Gating: KEY_SET_VALUE overlaps the alarm mask cached on the key handle
• Cardinality: once per delete through a handle whose mask covers it

The record that a registry value was deleted through a key handle, or that an attempt to delete one failed. Gated, staged and fixed at open exactly as lcs.audit.value.set is.

What was removed is recorded by type, length and SHA-256 digest: the effective value before the delete, read in the transaction's own view when the delete is transacted.

5.12.1 Fields #

Every record also carries the header fields of the envelope, which no payload repeats.

Generated from lcs.evman by pkm/tools/gen-events-book.py. Edit the fragment, not this page.

• Event type: lcs.audit.value.set
• Defined in: lcs.evman
• Tier: essential
• Gating: KEY_SET_VALUE overlaps the alarm mask cached on the key handle
• Cardinality: once per write through a handle whose mask covers it

The record that a registry value was written through a key handle, or that an attempt to write one failed. The key's SYSTEM_ALARM ACEs configure it: the ACEs that match the caller when the key is opened give the handle a continuous-audit mask, and every later write whose right overlaps the mask is recorded, as kacs.audit.handle.used does for files.

The mask is fixed when the key is opened. Removing the alarm ACE does not silence a handle already open, so the write that removes it is still recorded; equally, adding one does not reach handles opened before.

A transacted write is recorded when it is staged, not when it lands. outcome.success then means the source accepted it into the transaction; whether the transaction took effect is the matching lcs.audit.transaction.committed, joined on transaction.id.

A timed-out write may have been applied later. The source is not told to cancel, and when its reply arrives the kernel still applies the write's effects, with nothing recording who made it. Such a record says outcome.success false with request.timed-out true: read it as "may have been applied".

The data itself is never recorded, only its type, length and SHA-256 digest, with the same three for the value it replaced.

5.13.1 Fields #

Every record also carries the header fields of the envelope, which no payload repeats.

Generated from lcs.evman by pkm/tools/gen-events-book.py. Edit the fragment, not this page.

• Event type: lcs.config.value.rejected
• Defined in: lcs.evman
• Tier: essential
• Gating: none — every rejected configuration value is recorded
• Cardinality: once per rejected value

The record that LCS read one of its own configuration values, rejected it, and carried on with what it had. Identical in shape and meaning to kmes.config.value.rejected, differing only in which key the values live under.

Validation is reject-or-keep and never clamps, so this event is the only place where what an administrator wrote and what LCS is running on can be seen to differ.

Emission failure preserves the retained configuration — a failure to record the rejection must not change which value is in force.

5.14.1 Fields #

Every record also carries the header fields of the envelope, which no payload repeats.

Generated from lcs.evman by pkm/tools/gen-events-book.py. Edit the fragment, not this page.

• Event type: lcs.source.response.rejected
• Defined in: lcs.evman
• Tier: essential
• Gating: none — every rejection is recorded
• Cardinality: one record per occurrence

The record that LCS rejected data a registry source sent it. Sources are userspace backends serving configuration into the kernel, so this is the boundary where the kernel refuses to believe what userspace told it.

This is the one LCS event with no caller. It describes a source misbehaving rather than a principal acting, and there is frequently no principal involved — the data arrived on a source channel, not through a syscall.

The failure classes distinguish malformed structure from semantic impossibility: a security descriptor that will not parse is a different problem from a sequence number from the future or two layers claiming the same winning sequence.

5.15.1 Fields #

Every record also carries the header fields of the envelope, which no payload repeats.

Generated from lcs.evman by pkm/tools/gen-events-book.py. Edit the fragment, not this page.

• Event type: kmes.buffer.swap.failed
• Defined in: kmes.evman
• Tier: standard
• Gating: none — every failed swap is recorded, whatever the error
• Cardinality: once per failed swap

The record that KMES could not resize its per-CPU ring buffers and kept the capacity it had. A capacity change is a swap — new buffers at the new size, surviving events copied across, writers switched over — and this is what happens when that swap cannot be completed.

The failure is usually memory pressure, which makes it self-reinforcing in a way worth recognising: an administrator typically raises capacity because the system is dropping events, and the allocation most likely to fail is the one made while the system is already short of memory.

The other failures are rarer and more serious. EIO means the migration found a ring whose framing was corrupt and abandoned the swap rather than copy it; any other error is the kernel refusing to quiesce the CPUs for the switch-over. In every case the old rings stay live and nothing was lost by the attempt.

The swap is system-wide rather than per-ring, so no CPU or ring is named.

6.1.1 Fields #

Every record also carries the header fields of the envelope, which no payload repeats.

Generated from kmes.evman by pkm/tools/gen-events-book.py. Edit the fragment, not this page.

• Event type: kmes.config.applied
• Defined in: kmes.evman
• Tier: standard
• Gating: none — every configuration read that reaches the commit is recorded
• Cardinality: once per read of Machine\System\KMES

The record that KMES read its configuration key and committed what it found. Emitted after every read that gets as far as the commit: at boot once the registry is available, and again each time a value under the key changes.

The four counts account for every setting the read saw, so a record whose config.counts.applied is zero is a read that changed nothing, and one with config.counts.retained-invalid above zero comes with a kmes.config.value.rejected for each value kept back. A read whose BufferCapacity swap failed is still recorded here, because the other three settings commit without it; buffer.capacity is then the capacity kept, beside the kmes.buffer.swap.failed that says why.

6.2.1 Fields #

Every record also carries the header fields of the envelope, which no payload repeats.

Generated from kmes.evman by pkm/tools/gen-events-book.py. Edit the fragment, not this page.

• Event type: kmes.config.refresh.failed
• Defined in: kmes.evman
• Tier: essential
• Gating: none — every failed re-read is recorded
• Cardinality: once per failed read

The record that KMES could not read one of its configuration keys and kept running on what it had. Two keys are read this way: Machine\System\KMES, KMES's own settings, and Machine\Generic\Events, the emission policy that decides which kernel event types are written.

A failed read changes nothing. KMES keeps the configuration it last committed, or the compiled-in defaults if it never committed one, and the emission policy keeps the switches it last computed, or the tier defaults. Until the next change under the key, the registry and the running kernel disagree, and this record is the only sign of it: an administrator who switched an event type off and finds it still written is looking for one of these.

The usual cause is the registry source failing to answer in time. A configuration rejected value by value is not a failed read; that is kmes.config.value.rejected.

6.3.1 Fields #

Every record also carries the header fields of the envelope, which no payload repeats.

Generated from kmes.evman by pkm/tools/gen-events-book.py. Edit the fragment, not this page.

• Event type: kmes.config.value.rejected
• Defined in: kmes.evman
• Tier: essential
• Gating: none — every rejected configuration value is recorded
• Cardinality: once per rejected value

The record that KMES read a configuration value, rejected it, and carried on with what it had. Emitted when the stored value is missing, of the wrong type, or out of range.

Validation is reject-or-keep, never clamp: a valid value is applied and an invalid one is ignored, with the last known-good value retained. That makes this event the only place the divergence is visible — the registry records what an administrator wrote, and this records what KMES is running on. An operator reading only the registry will believe a change took effect that did not.

These records are emitted before the configuration commit and are deliberately not part of the commit decision: a failure to construct one must never roll back a hot-swap that otherwise succeeded.

6.4.1 Fields #

Every record also carries the header fields of the envelope, which no payload repeats.

Generated from kmes.evman by pkm/tools/gen-events-book.py. Edit the fragment, not this page.

• Event type: ntfe.policy.published
• Defined in: ntfe.evman
• Tier: standard
• Gating: none — every generation of rules that goes into force is recorded
• Cardinality: once per published generation of rules

The record that a new generation of traffic rules went into force. The kernel reads its own policy from Machine\System\Network\Rules, a short while after the registry changes, and publishes it whole: from this point every traversal is judged by these rules, and every flow judged under the old ones is judged again on its next packet.

A re-read that finds the policy exactly as it was published publishes nothing and writes no record, so writing a rule back unchanged, or netd writing its inventory, is silent. A refused policy writes ntfe.policy.rejected instead, and the generation before it stays.

Not every generation has one of these. A change to the network context (which network each interface is on, and its trust) advances the same generation counter without a new rule set, and writes no record. A verdict whose policy.generation falls between two of these records was judged by the rules of the earlier one.

7.1.1 Fields #

Every record also carries the header fields of the envelope, which no payload repeats.

Generated from ntfe.evman by pkm/tools/gen-events-book.py. Edit the fragment, not this page.

• Event type: ntfe.policy.rejected
• Defined in: ntfe.evman
• Tier: essential
• Gating: a refusal unlike the last one recorded
• Cardinality: once per distinct refusal

The record that the kernel read a traffic policy and refused it, so the policy an administrator wrote is not the policy in force. NTFE accepts or refuses a policy whole: one bad rule anywhere refuses every layer, and the previous generation goes on judging traffic exactly as before. Nothing is half-applied. The registry shows what was written; this shows that it did not take.

The kernel reads the policy again whenever anything under Machine\System\Network changes, including netd's inventory, and a broken policy is refused by every read until it is fixed. The same refusal of the same policy is recorded once: a new record means the policy or the reason changed. A policy that is accepted, or found unchanged, starts the count again.

The rule, where there is one, is the place to look: outcome.reason says what is wrong with it.

7.2.1 Fields #

Every record also carries the header fields of the envelope, which no payload repeats.

Generated from ntfe.evman by pkm/tools/gen-events-book.py. Edit the fragment, not this page.

• Event type: ntfe.verdict.reported
• Defined in: ntfe.evman
• Tier: essential
• Gating: an explicit report directive in the matching rule
• Cardinality: once per matching evaluation

The record of a traffic policy decision that a rule explicitly asked to be reported. Not a record of every decision — the engine evaluates constantly and reports only where a rule says to.

A stock machine emits none of these. The shipped baseline rule set contains no report directives, so this event exists and never fires until an administrator adds one. Absence of these records says nothing about whether traffic was evaluated.

The engine's own record of every verdict goes to a private ring read by the userspace policy daemon, not to the event stream, and is overwritten when no reader is attached. So the complete decision history is neither in the event stream nor durable.

Address, port and protocol fields are conditional on how far up the stack evaluation reached: traffic matched at the raw-packet layer has no addresses to record.

7.3.1 Fields #

Every record also carries the header fields of the envelope, which no payload repeats.

Generated from ntfe.evman by pkm/tools/gen-events-book.py. Edit the fragment, not this page.

• Event type: peinit.boot.downgraded
• Defined in: peinit.evman
• Tier: essential
• Gating: none
• Cardinality: one per finding that forced the downgrade, at most once a boot in all

A full boot was downgraded to safe mode: the machine is running a reduced service set. The services named are not marked failed, because safe mode never meant to start them, so this record is the only one that names them as the cause. Essential because it is rare and changes what the whole machine is running.

Formerly boot.safe_mode_downgrade.

8.1.1 Fields #

Every record also carries the header fields of the envelope, which no payload repeats.

Generated from peinit.evman by pkm/tools/gen-events-book.py. Edit the fragment, not this page.

• Event type: peinit.cgroup.leaked
• Defined in: peinit.evman
• Tier: standard
• Gating: none
• Cardinality: once per cgroup, the first time it is found still populated after its post-kill deadline

A cgroup could not be reclaimed: its processes do not respond to the kernel, and the cgroup is leaked. It is one of a service's sub-cgroups, or the whole cgroup of a submitted job.

Formerly cgroup.leaked.

8.2.1 Fields #

Every record also carries the header fields of the envelope, which no payload repeats.

Generated from peinit.evman by pkm/tools/gen-events-book.py. Edit the fragment, not this page.