You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@maka.apache.org by "2BAB (via GitHub)" <gi...@apache.org> on 2026/10/21 12:47:47 UTC
[I] bug(runtime-host): managed service crash-loops after a storage-root remount [maka]
2BAB opened a new issue, #6224:
URL: https://github.com/apache/maka/issues/6224
### What happens
After a normal macOS reboot, the **managed** Runtime Host never comes up and launchd keeps restarting it:
```
$ maka runtime-host service status
Runtime Host service is failed at ws://127.0.0.1:64150/runtime-host
```
`~/Library/Logs/Maka/runtime-host-services/*.stderr.log` repeats:
```
StorageRootAuthorityError: Storage root marker belongs to a different directory:
/Users/<user>/Library/Application Support/Maka/workspaces/default
at confirmRootSnapshot (@maka/storage/dist/root-authority.js)
at async startExecutionRuntimeHostService (@maka/runtime-host/dist/server/execution-service.js)
```
### Root cause
The same one #1702 describes: `.maka-storage-root.json` binds `{dev, ino}`, and `st_dev` is a per-mount number on APFS that changes across reboots while the inode does not.
| | marker | live `stat` |
| --- | --- | --- |
| dev | 16777233 | **16777230** |
| ino | 361659622 | 361659622 |
`markerMatchesIdentity` requires both fields, so a remount reads as "another directory".
### Why this is still a bug after #1702
The desktop app repairs its root — a second root on this machine had its marker refreshed automatically right after the same reboot — but the managed service never passes `--repair-root-after-remount` and has no UI to ask, so it can only fail and be restarted.
`root-authority.ts` already calls the repair an "explicit recovery boundary … callers must obtain user intent for this exact candidate first"; the service path simply has no caller to supply that intent.
### Suggested fixes, cheapest first
1. In the managed service, when `ino` still matches and only `dev` changed, repair the marker and log the decision (the inode is the identity; `dev` is mount bookkeeping).
2. Or report `root_remounted` to the client and let the app ask the user once, instead of crash-looping.
3. Longer term, bind the marker to a stable volume identifier (`statfs` `f_fsid` or the APFS volume UUID) rather than `st_dev`.
### Environment
- CLI built from a source checkout (`packages/cli/dist/cli.js`, version 0.2.2)
- macOS 15 arm64, single workspace `Maka/workspaces/default`
- Runtime Host managed by the `com.maka.runtime-host.*` launch agent
---
*Report drafted with Claude (Anthropic) and reproduced/verified by the reporter; the reproduction above was run on the reporter's machine.*
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@maka.apache.org.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@maka.apache.org
For additional commands, e-mail: commits-help@maka.apache.org
Re: [I] bug(runtime-host): managed service crash-loops after a storage-root remount [maka]
Posted by "Dante-dan (via GitHub)" <gi...@apache.org>.
Dante-dan commented on issue #6224:
URL: https://github.com/apache/maka/issues/6224#issuecomment-6317586628
I traced this to the supervised service resolving the root in `startExecutionRuntimeHostService` before it can acquire managed launch authority. The desktop recovery added by #1538 does not cover that path.
I propose an explicit, one-shot recovery path for the installed managed service:
- Surface the identity mismatch with actionable recovery guidance, rather than suggesting that restarting the service will fix it.
- Let the operator prepare the exact root repair candidate, show its canonical path and durable root ID, and request confirmation before applying it. Revalidate the managed deployment generation and the prepared marker/directory snapshot before committing the repair, preserving the existing root ID.
- Keep normal supervised startup strict. A matching inode on a different device cannot distinguish a remount from a copy on another volume, so I would retain `dev + ino` checks and avoid storing a persistent repair flag in the LaunchAgent.
- Cover the managed recovery path, declined confirmation, changed candidate/deployment, and ordinary startup refusing a stale marker using the existing CLI/runtime-host/storage test suites.
This follows the existing snapshot-bound desktop recovery boundary while giving the headless service an explicit operator route. The evidence so far is the reported marker/stat pair plus code-path analysis; I have not reproduced a reboot on the reporter's machine.
— Codex (automated contribution under user direction)
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@maka.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@maka.apache.org
For additional commands, e-mail: commits-help@maka.apache.org
Re: [I] bug(runtime-host): managed service crash-loops after a storage-root remount [maka]
Posted by "Dante-dan (via GitHub)" <gi...@apache.org>.
Dante-dan commented on issue #6224:
URL: https://github.com/apache/maka/issues/6224#issuecomment-6317587772
take
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@maka.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@maka.apache.org
For additional commands, e-mail: commits-help@maka.apache.org