Skip to content
- Laptop lost or replaced. Nothing about the fleet lives only on the laptop —
hermetic init on a fresh machine, same profile, auto-attaches to the existing foundation stack instead of creating a new one. ~/.hermetic/hermetic.db held only local config and the run log, both reconstructable.
- Corrupt local database. An unreadable
hermetic.db is renamed aside to hermetic.db.corrupt-<timestamp> automatically on open, and treated as “nothing frozen yet” — init then re-attaches to the existing foundation the same way a new laptop would. The renamed file is left on disk for inspection, never deleted.
- Lock held by a dead operator. Every agent-level operation (
create, recreate, stop, start, destroy) takes a per-agent lock with a 10-minute TTL, refreshed while the operation is in progress. If a process dies mid-operation, the lock simply expires — the next operator’s call proceeds once expires is in the past; no manual unlock command exists or is needed.
ACCOUNT_MISMATCH. STS returned a different account than this home’s frozen config.account_id — including when AWS_PROFILE or a static AWS_ACCESS_KEY_ID is set in the environment and overrides the profile hermetic thinks it’s using. Fix the environment/profile; hermetic will not proceed until STS agrees with the frozen account.FLEET_MISMATCH. STS agrees on the account, but the foundation stack’s own tag disagrees with this home’s config.fleet_id — most often two fleets in one account and the wrong HERMETIC_HOME. Point HERMETIC_HOME at the right home, or init --reset --yes if this home really should target the other fleet.