mara/hyperhive
mara/hyperhive
Watch
0
0
Fork
You've already forked hyperhive
 0
Code Activity

hive-priv: write a configured stable exe path into unit drop-ins

Browse source 
HIVE_PRIV_EXE, set by the module to the /run/hive-rootfs-check link, is
checked at start and used for the drop-in's ExecStartPre. Without it the
running binary's path is used as before, and an unlinked one gets an
error that names the cause.
This commit is contained in:
atlas 2026-11-15 16:34:25 +01:00 • committed by mara
commit ca51bb9d54
1 changed files with 172 additions and 41 deletions
Download patch file Download diff file Expand all files Collapse all files

15
docs/4-implementation/agent-state/persistence.md
View file

@ -354,10 +354,17 @@ path and its type when:
Absent paths pass, so a first start works. The check neither deletes nor
repairs: the operator removes the offending entry, and the next start goes
through.
The drop-in names the `hive-priv` binary that wrote it, so a drop-in never
points at a build without the sub-command. A drop-in written by an older
points at a build without the sub-command. That build's store path has a GC
root, `/nix/var/nix/gcroots/hyperhive-check-rootfs/h-<name>`, written before the
The drop-in runs the binary named by `HIVE_PRIV_EXE`, which `hive-priv.nix` sets
to `/run/hive-rootfs-check`, the link to the current build. That path doesn't
change and lies outside the store, so a garbage collection, or a switch that
leaves `hive-priv.service` running, can't strand a drop-in on a missing binary.
`hive-priv` checks the value when it starts (an absolute path of letters,
digits and `/._+-` that exists) and refuses to start otherwise. Without
`HIVE_PRIV_EXE`, as under an older module, the drop-in names the running
binary's own path; once someone unlinks that file the write fails with an error
that says so, until `hive-priv.service` restarts. A store path named that way
has a GC root, `/nix/var/nix/gcroots/hyperhive-check-rootfs/h-<name>`, written
before the
drop-in and replaced on each write, so a garbage collection can't remove the
binary a restart would run. The directory sits beside `gcroots/per-container`,
which is the only gcroots path bound into a container, so only root writes it.