Summary
The Docker VM's configured memory limit (memory_mib) was silently lost after the OrbStack daemon exited spontaneously (clean exit, no user action) and auto-relaunched. The setting had been explicitly set to 6144; after the spontaneous restart, orbctl config show reported memory_mib: 4096 (= 1/4 of host RAM, i.e. the default formula for this 16 GB machine) and the VM booted with 4 GB. Nothing on the machine ran orbctl config set in the interim (verified — full shell/session history audited).
A 33-container workload that had been running fine in 6 GB immediately OOM-thrashed in 4 GB: sustained pagefault_out_of_memory in the guest kernel, vmgr at 600–770% host CPU, and Docker API calls (docker stats/logs/exec) taking minutes or timing out.
Environment
- OrbStack 2.2.0 (2020000) at time of incident; since updated to 2.2.1
- macOS 26.5.1, Apple Silicon Mac mini, 16 GB RAM
- Docker-only usage (no Linux machines), ~33 containers
Timeline (log excerpts captured before rotation)
Jul 27 — memory limit explicitly set and applied (VM restarted afterward; ran at 6 GB for 6 days):
$ orb config get memory_mib
8192
$ orb config set memory_mib 6144
Restart OrbStack with "orb stop" to apply changes.
$ orb config get memory_mib
6144
Aug 2, 16:29 — spontaneous daemon exit + auto-relaunch, no user interaction (from gui.log; the GUI app had been running since Jul 16):
2026-08-02 16:29:41.940 OrbStack[399:4246] docker changed
2026-08-02 16:29:41.947 OrbStack[399:4246] synthetic state -> starting
2026-08-02 16:29:41.951 OrbStack[399:4246] k8s changed
2026-08-02 16:29:43.289 OrbStack[399:10629422] Daemon exited: status 0
2026-08-02 16:29:43.289 OrbStack[399:10629422] Host exit diagnostics:
2026-08-02 16:29:43.289 OrbStack[399:4246] synthetic state -> stopped
2026-08-02 16:29:46.392 OrbStack[399:4246] Daemon started: pid 63614
The relaunched vmgr logged update available immediately (time="08-02 16:29:47" level=info msg="update available") — possibly coincidental, but it was the only notable event at that moment.
The relaunched VM booted with 4 GB, not the configured 6 GB (from that boot's vmgr log — zram is sized ≈ VM RAM):
👾 kernel | [ 0.201253] zram0: detected capacity change from 0 to 8126632
👾 kernel | [ 0.206155] Adding 4063312k swap on /dev/zram0.
(compare a later 8 GB boot: Adding 8177724k swap)
...and began thrashing within a minute:
👾 kernel | [ 43.149469] pagefault_out_of_memory: 5 callbacks suppressed
👾 kernel | [ 125.257107] pagefault_out_of_memory: 7 callbacks suppressed
👾 kernel | [ 211.323566] pagefault_out_of_memory: 2 callbacks suppressed
👾 kernel | [ 961.451749] pagefault_out_of_memory: 5 callbacks suppressed
👾 kernel | [ 1157.472396] pagefault_out_of_memory: 35 callbacks suppressed
Aug 2, ~20:20 — config store confirmed reverted:
$ orbctl config show | grep memory_mib
memory_mib: 4096
What it is NOT
- Not a manual change: no
config set was executed by anyone/anything between Jul 27 and the incident (session histories audited).
- Not reproducible on demand: the setting survived both a subsequent manual
orbctl stop/start cycle and the 2.2.0 → 2.2.1 updater restart. It appears tied specifically to whatever caused the spontaneous daemon exit at 16:29.
Questions
- Is this a known failure mode? Where does
memory_mib persist, and is there a write path during daemon shutdown/startup that could lose or regenerate it with defaults?
- What would cause a clean (
status 0) spontaneous daemon exit with an empty "Host exit diagnostics" while the GUI was untouched?
Happy to provide more detail — though note the incident-boot logs have since rotated out (only two vmgr logs are retained); the excerpts above were captured before rotation.
Summary
The Docker VM's configured memory limit (
memory_mib) was silently lost after the OrbStack daemon exited spontaneously (clean exit, no user action) and auto-relaunched. The setting had been explicitly set to6144; after the spontaneous restart,orbctl config showreportedmemory_mib: 4096(= 1/4 of host RAM, i.e. the default formula for this 16 GB machine) and the VM booted with 4 GB. Nothing on the machine ranorbctl config setin the interim (verified — full shell/session history audited).A 33-container workload that had been running fine in 6 GB immediately OOM-thrashed in 4 GB: sustained
pagefault_out_of_memoryin the guest kernel, vmgr at 600–770% host CPU, and Docker API calls (docker stats/logs/exec) taking minutes or timing out.Environment
Timeline (log excerpts captured before rotation)
Jul 27 — memory limit explicitly set and applied (VM restarted afterward; ran at 6 GB for 6 days):
Aug 2, 16:29 — spontaneous daemon exit + auto-relaunch, no user interaction (from
gui.log; the GUI app had been running since Jul 16):The relaunched vmgr logged
update availableimmediately (time="08-02 16:29:47" level=info msg="update available") — possibly coincidental, but it was the only notable event at that moment.The relaunched VM booted with 4 GB, not the configured 6 GB (from that boot's vmgr log — zram is sized ≈ VM RAM):
(compare a later 8 GB boot:
Adding 8177724k swap)...and began thrashing within a minute:
Aug 2, ~20:20 — config store confirmed reverted:
What it is NOT
config setwas executed by anyone/anything between Jul 27 and the incident (session histories audited).orbctl stop/startcycle and the 2.2.0 → 2.2.1 updater restart. It appears tied specifically to whatever caused the spontaneous daemon exit at 16:29.Questions
memory_mibpersist, and is there a write path during daemon shutdown/startup that could lose or regenerate it with defaults?status 0) spontaneous daemon exit with an empty "Host exit diagnostics" while the GUI was untouched?Happy to provide more detail — though note the incident-boot logs have since rotated out (only two vmgr logs are retained); the excerpts above were captured before rotation.