simpletest/who_need_help
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Record persistent external monitoring

Browse Source
This commit is contained in:
SimpleTest 2026-08-25 23:41:38 +03:00
parent 18ce9c174b
commit e799e5e791
2 changed files with 23 additions and 11 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

24
docs/public-launch-checklist.md
View File

@ -164,13 +164,13 @@ ssh buyvm-maya \
The linger check must print `yes`; otherwise the enabled user timer can depend
on an active login session and is not a persistent external monitor.
A read-only check on 2026-08-25 returned `linger=no` for `simple` on the
selected external host. The timer was loaded, enabled, and active while the
user manager was running, and its latest completed check reported readiness,
metrics, and backup freshness as `up`; those facts do not prove that the user
manager survives logout or starts at boot. Persistent off-site monitoring
therefore remains open until an administrator enables lingering and the timer
is rechecked after a login-independent restart.
The 2026-08-25 pre-change check returned `linger=no` for `simple` on the
selected external host. The reviewed change then enabled lingering for that
exact user. A separate SSH session observed `linger=yes`, the monitor timer
enabled and active, and a manually triggered service result of `success` with
readiness, aggregate metrics, and restore-verified backup freshness all `up`.
Per the installed `loginctl(1)` documentation, the enabled lingering state
starts the user manager at boot and keeps it after logout.
Do not mark backup ownership complete merely because this command passes. The
operator must still store the Restic key independently and approve retention,
@ -225,10 +225,12 @@ as forward-only rather than receiving an invented database rollback.
with the run prefix. Anonymous contact verification still requires a
controlled production mail smoke before this combined item can be
checked.
- [ ] Database, application, worker, email, push, backup, and edge monitoring
are visible to the responsible operator and persist independently of an
interactive login. Current checks prove visibility while the external
user manager is running, but that host still reports `linger=no`.
- [x] Database, application, worker, email, push, backup, and edge monitoring
are visible through public readiness plus bounded aggregate metrics and
the restore-verified backup heartbeat. The independent monitor timer is
enabled and active, its latest forced check reported every configured
boundary `up`, and the external user has `linger=yes` so its user manager
starts at boot and remains after logout.
Record observed timestamps, revision/image identities, and non-secret evidence
paths in `docs/verification.md`. Record failed checks as failed; do not convert

10
docs/verification.md
View File

@ -38,6 +38,16 @@ results from product limits and unknown production properties.
- Both authentication messages opened for this verification were returned to
Gmail's unread state. The task-owned verification tab was closed; the user's
pre-existing Chrome process and tabs remained open.
- The independent monitor host initially reported `Linger=no` for user
`simple`, while `who-need-help-production-monitor.timer` was enabled and
active. The installed `loginctl(1)` documentation states that enabling
lingering starts the user's manager at boot and keeps it after logout.
`loginctl enable-linger simple` changed only that user-level persistence
setting. A separate SSH session then observed `Linger=yes`, the timer still
enabled and active, and a manually triggered monitor service result of
`success` with readiness, aggregate metrics, and restore-verified backup
freshness all `up`. The backup age was 35,362 seconds against the configured
129,600-second alert threshold.
- The frozen test, shared Caddy, Google Play Console, and the public remote
repository were not changed by this work.