Filed unassigned and ungraded by the #12828 dev (session session_01CPrUz21stTFhJRUirdc4yw) while correcting the source comment in scripts/pm/os-verify-lock.sh. Explicitly fenced out of #12828 by its triage — "真要做,单独立卡" — so it is recorded here rather than folded in.
What is now measured
Two independent readings, on two different boxes, against two different ledger files. Each carries both controls in one command, because a zero is only a reading if the instrument can also return non-zero.
| #12828, 2026-08-28T01:00Z | PR #12916, 2026-08-28T08:26Z |
|---|
/proc/uptime | 608s, derived boot 00:50:13Z | 619s, derived boot 08:15:53Z |
| ledger records | 74, first 2026-08-27T16:51:12Z | 14, first 2026-08-28T06:12:34Z |
ledger file birth (stat %W) | 2026-08-27T16:51:12Z | 2026-08-28T06:12:34Z |
| records at or after derived boot | 0 | 0 |
| records before derived boot | 74, oldest by 8h11m | 14, oldest by 2h03m |
| positive control — a file touched at that moment | read as AFTER derived boot | read as AFTER derived boot |
| negative control — PID 1 vs derived boot | started 0.32s after | started 0.27s after |
In both, every record and the ledger file itself predate the boot the uptime clock reports. The positive control says the comparison is live. The negative control says /proc/uptime and the process tree agree with each other — so it is the filesystem that did not restart with them, not the clock that is wrong.
What is NOT measured, and is the whole of this card
⛔ Not that /tmp survives a reset. Two readings disqualify a mechanism; they do not establish its negation. What actually happens to /tmp across a restart on these hosts — always, sometimes, under which restart kind, for how long, on which fleet — is uncharacterised, and neither reading above was designed to answer it. Both are single-container, single-moment observations that happen to point the same way.
The measurement this needs is a real one, which is exactly why it was fenced out of a comment-correction card:
- several restarts, of each kind the fleet actually performs (a stop/start, a rebuild, a host migration, an idle reap);
- several containers, so a per-host quirk does not read as a fleet rule;
- a marker written before the restart and looked for after it, not an inference from a clock;
- the same two controls each time, so a null result stays a reading.
Why it is worth doing rather than leaving
The #12783 triage fenced ledger persistence out under two constraints: this file must create nothing that outlives a process and needs reaping, and the ledger must never redden a gate. Both were reasoned against a ledger believed to be reliably per-container and ephemeral. On the two boxes measured it is neither — the file already outlives every process that writes it, is already unreaped except by LEDGER_MAX_BYTES, and has now been observed predating a reported boot twice.
⛔ That does not reopen the persistence decision and this card does not ask for it to be reopened. It says the input that decision would need does not exist yet. The current situation is arguably worse than reliably-ephemeral: a population whose lower bound moves for reasons nobody has characterised is harder to reason about than one that resets predictably, and --report and the slot-ageing comment both now have to say "the floor is the file, reason unasserted" because that is genuinely all anyone knows.
Not blocked on anything, and blocking nothing
The code in scripts/pm/os-verify-lock.sh is already honest as of PR #12916 and PR #12827: both state the population floor as the first record, with the reason left unasserted, so nothing in the tree is currently claiming a mechanism it cannot support. This card is the measurement that would let a future author claim one.
Refs
Filed unassigned and ungraded by the #12828 dev (session
session_01CPrUz21stTFhJRUirdc4yw) while correcting the source comment inscripts/pm/os-verify-lock.sh. Explicitly fenced out of #12828 by its triage — "真要做,单独立卡" — so it is recorded here rather than folded in.What is now measured
Two independent readings, on two different boxes, against two different ledger files. Each carries both controls in one command, because a zero is only a reading if the instrument can also return non-zero.
/proc/uptimestat %W)In both, every record and the ledger file itself predate the boot the uptime clock reports. The positive control says the comparison is live. The negative control says
/proc/uptimeand the process tree agree with each other — so it is the filesystem that did not restart with them, not the clock that is wrong.What is NOT measured, and is the whole of this card
⛔ Not that
/tmpsurvives a reset. Two readings disqualify a mechanism; they do not establish its negation. What actually happens to/tmpacross a restart on these hosts — always, sometimes, under which restart kind, for how long, on which fleet — is uncharacterised, and neither reading above was designed to answer it. Both are single-container, single-moment observations that happen to point the same way.The measurement this needs is a real one, which is exactly why it was fenced out of a comment-correction card:
Why it is worth doing rather than leaving
The #12783 triage fenced ledger persistence out under two constraints: this file must create nothing that outlives a process and needs reaping, and the ledger must never redden a gate. Both were reasoned against a ledger believed to be reliably per-container and ephemeral. On the two boxes measured it is neither — the file already outlives every process that writes it, is already unreaped except by
LEDGER_MAX_BYTES, and has now been observed predating a reported boot twice.⛔ That does not reopen the persistence decision and this card does not ask for it to be reopened. It says the input that decision would need does not exist yet. The current situation is arguably worse than reliably-ephemeral: a population whose lower bound moves for reasons nobody has characterised is harder to reason about than one that resets predictably, and
--reportand the slot-ageing comment both now have to say "the floor is the file, reason unasserted" because that is genuinely all anyone knows.Not blocked on anything, and blocking nothing
The code in
scripts/pm/os-verify-lock.shis already honest as of PR #12916 and PR #12827: both state the population floor as the first record, with the reason left unasserted, so nothing in the tree is currently claiming a mechanism it cannot support. This card is the measurement that would let a future author claim one.Refs
/proc/uptimereported 608s while all 74 records predated that boot, so "starts empty on every reset" is not reliable #12828 — the comment correction; the first reading, and the ruling that fenced this outos-verify-lockledger lives in the container's /tmp, so--reportcan never answer the question it was built for — "where does hold time go" is scoped to one shift, and says so nowhere #12783 — the scope disclosure on--report, where persistence was first fenced