`_is_ancestor_pid` asked psutil for the whole parent chain at once:
any(parent.pid == pid for parent in psutil.Process().parents())
`Process.parents()` is eager: it walks all the way to the lowest pid
*before* returning a list, so the generator expression cannot
short-circuit when it reaches the matching ancestor. Its per-link
`parent()` tolerates only `NoSuchProcess`, so any process we may not
inspect anywhere above us raises `AccessDenied` out of the whole call,
and the `except Exception` guard discards every ancestor already found,
including the orchestrator one link down.
Under firejail with `ptrace_scope=1`, and in hardened containers,
`/proc/1` is exactly that unreadable process. The hand-off child then
failed to recognize its own parent's fresh marker, `UpdateLock.acquire`
treated a live orchestrator as a foreign concurrent updater, and the
in-app update exited 2 ("Another Hermes update is already running",
naming the hand-off script's own pid) on every attempt, indefinitely.
Walk the chain one link at a time and test each ancestor as it is
discovered, so a failure above a match can no longer erase it. A
failure encountered before any match still returns False, keeping the
conservative refusal for genuinely unprovable ancestry. The walk is
bounded by `_MAX_ANCESTRY_DEPTH` and skips a repeated pid so an
unexpected chain cannot spin.
Fixes#87514
On Windows, subprocess text=True without an explicit encoding decodes
child output with the ANSI code page (e.g. 'gbk'); non-ASCII bytes then
raise UnicodeDecodeError inside subprocess._readerthread, killing the
Hermes backend before it becomes ready and surfacing as the desktop boot
timeout.
Sweep every hermes_cli text=True subprocess call to encoding='utf-8',
errors='replace', and add an AST-based regression test that fails when a
future text-mode call omits the encoding.
Fixes#55658
Adopting a killed update's marker verbatim kept its started_at. When that
claim was close to the 20-minute ceiling, the retry's own lock expired
seconds into its run and a second updater could start over the same
checkout: live, a detached `hermes update` acquired the lock 6s after the
retry adopted a claim 3s from expiry.
A marker naming our pid can only be a dead predecessor's (nothing
pre-writes one for `hermes update`, which always runs under a parent's
claim), so it is a new attempt and is claimed fresh like any dead holder's.
Only one acquire runs per process, so this cannot renew a wedged update.
A `hermes update` killed after taking the lock leaves
`.hermes-update-in-progress` naming its pid. In a container every restart
starts pid numbering over, so the retry is routinely handed that same pid; the
liveness probe then found the "holder" alive (it is the retry itself) and
refused with "Another Hermes update is already running (process 2)" until the
20-minute age ceiling expired.
No other live process can hold our pid, so `UpdateLock.acquire` now treats a
marker naming `os.getpid()` as ours and adopts it verbatim, the same rule
`UpdateMarkerGuard::acquire` in the desktop updater already applies.
started_at is kept so repeated retries cannot hold a wedged update under the
age ceiling.
Co-authored-by: ZT-Toolkit <296727067+ZT-Toolkit@users.noreply.github.com>
A desktop hand-off on Windows stalled at "Another Hermes update is already
running (process <the hand-off itself>)". The hand-off PowerShell claims the
marker and runs the old `hermes update`, whose _old_updater shim spawns
_update_takeover.py as python -I -S -B. HERMES_UPDATE_HANDOFF_PID names the
old updater, not the marker owner, so adoption relies on the ancestry walk;
without psutil (-S) that walk falls back to /proc or ps, and Windows has
neither, so the grandchild refused its own orchestrator and exited 2.
Read the parent pid from a Toolhelp32 snapshot through stdlib ctypes, and
treat a parent created after its child as a recycled pid, as psutil does.
Reproduced and verified on a real Windows venv: the grandchild now adopts
its ancestor's marker and still refuses an unrelated live holder.
The regression tests were unmarked, and the Windows lane imports only files
carrying a platforms marker, so the Windows half never ran: mark both
stdlib-walk tests for every lane.
Also print a line when the old updater hands off to the new (PM) updater,
so logs show where the switch happened.
The desktop hand-off shim writes the update marker with its own pid and
spawns 'hermes update' as a direct child (adopts via getppid). An
old-updater update into a PM tree hands off again:
_old_updater._run_child spawns _update_takeover.py as 'python -I -S -B',
where psutil cannot import (-S skips site-packages). The psutil-only
ancestry walk then returned False for the two-hops-up shim, so the
takeover child refused its own orchestrator: 'Another Hermes update is
already running (PID <the shim itself>)', exit 2, and the dependency
stage never ran.
Add a stdlib ppid-chain fallback (/proc on Linux, ps on macOS) behind
the ImportError; psutil stays the fast path. Regression test spawns the
real three-process topology and is red on the old code.
Squashed integration of the user-facing message audit for this surface set.
Full per-finding receipts: /tmp/ux-audit/lanes/*-receipt.md (campaign artifacts).
Run historical updater completion in a fresh interpreter so cached imports
cannot revive retired dependency installers. Share Git and ZIP completion,
carry receipt and recovery state, and preserve child exit status.
Route plugin admission, binary acquisition, desktop launch and build paths
through PM. Replace redundant helpers and tests with real worker, package,
publication and launch checks. Keep the shipped compatibility surface fixed.
Targeted Python and desktop checks pass. Native update journeys and fresh
production image qualification remain pending. This is a checkpoint before
those acceptance runs.
Read text files with the encoding utf-8-sig so a BOM at the start of a
file does not cause a Unicode decode error (Windows editors add BOMs).
Reconstructed from ethie/pm commits 48a32b135b + 013219e814 onto the
current upstream/main base: only the utf-8 -> utf-8-sig transforms were
carried (370 exact line pairs across 205 files); pm-rename hunks that
rode in the original commit were left to the pm-store commit, and
utf8sig hunks entangled with content changes ride their owning commit.
Rebuilt on ethie/pm-clean off ac6c8028e0 (upstream/main).
The stale-staged-updater deadlock is not Windows-specific: hermes-setup
under ~/.hermes is only refreshed by a full installer run
(copy_self_to_hermes_home no-ops during --update), so every desktop whose
staged updater predates the HERMES_UPDATE_HANDOFF_PID export (8c76fe19)
runs an old parent that never sends the env var against a new child that
demands it — exit 2 ('Hermes is still running') forever, on macOS and
Linux just as on Windows.
Replace the wmic ancestry walk (deprecated, absent on current Win11,
GBK decode juggling) with psutil.Process().parents() — psutil is already
a hard dependency and is the project's canonical no-kill process probe.
Drop the os.name == 'nt' gate so all platforms heal. Add tests: a marker
owned by our parent process is recognized as our orchestrator; a live
non-ancestor holder is still refused.
On Windows the Tauri updater writes its PID to the update marker, then
spawns 'hermes update' via the venv shim. The child receives
HERMES_UPDATE_HANDOFF_PID to recognize the parent lock, but on some
Windows configs the env var is not inherited through the shim subprocess
chain, deadlocking every GUI update.
Fix: when the env-var handoff fails, fall back to walking the Windows
process tree via wmic /format:csv to collect ancestor PIDs. If the
marker PID is found in the ancestor chain, treat it as our own
orchestrating parent and allow the update.
Also fixes wmic output encoding on localized Windows (GBK/CP936) by
using /format:csv which produces clean UTF-8 output.
The cross-process update lock (fe8e4d93d) made the in-progress marker
mutually exclusive across every update entrypoint — but the Tauri
updater holds that marker for its WHOLE run and then spawns
hermes update as a child stage. The child read the marker, found its
own parent's live pid, refused with exit 2, and the GUI mapped that to
"Hermes is still running. Close all Hermes windows and try the update
again." Retry spawns a fresh updater that deadlocks against itself the
same way, so every GUI-driven update dead-ends on the failure screen
with no winnable retry (observed: three consecutive self-refusals in
bootstrap-installer.log within 90 seconds).
Hand the claim off explicitly: update_child_env exports
HERMES_UPDATE_HANDOFF_PID naming the updater's own pid, and
UpdateLock.acquire treats a live holder matching that pid as the lock
we are already running under — run without claiming, and release
leaves the parent's marker untouched. The env var alone grants
nothing: the pid must also be the live marker owner, so a stale or
forged value cannot bypass the lock, and a dashboard-spawned
hermes update (no handoff env) is still refused exactly as before.
The Windows-footgun linter caught a real bug in the new update lock. On
Windows os.kill(pid, 0) is not a no-op: CPython routes sig=0 to
GenerateConsoleCtrlEvent, which sends Ctrl+C to the target's entire
console process group (bpo-14484). The liveness probe would have killed
the very updater it was asking about -- and any sibling sharing that
console.
Delegate to gateway.status._pid_exists, the project's existing no-kill
probe, which uses psutil (OpenProcess/GetExitCodeProcess on Windows) and
also reports zombies as dead. Any pid we cannot evaluate still counts as
dead so a corrupt marker cannot wedge the lock.
Three surfaces start updates against one checkout: a terminal
"hermes update", the dashboard's Update button (which spawns that same
command detached), and the desktop's, which hands off to the Tauri
updater. Only the Tauri updater published the in-progress marker, and
only Electron read it -- to gate backend startup, not to stop a second
updater. So a dashboard-spawned update and an installer-driven git
checkout could mutate the same tree concurrently, rewriting source under
a live interpreter.
Claim the same marker from cmd_update rather than adding a second
mechanism: same path, same pid+started_at payload the Rust and Electron
readers already parse. A marker only counts as live when its pid is alive
and it is inside the shared age ceiling, so a crashed updater self-heals
instead of wedging every future update. Release only removes a marker we
still own, leaving a handoff partner's claim intact.
Refusing exits 2, matching the existing concurrent-instance contract the
Tauri updater already recognizes.
