Repository navigation
dockma 0.7.0
Pre-release
Pre-release
Added
- Changes made on the Mac to a bind mount under home now fire inotify events in containers, so file watchers like
vite,nodemonandwebpack --watchpick up edits. The guest's own writes aren't reported back to it twice. Needs the new guest (dockma installormake guest install-guest); an older guest keeps working without the events. The agent is 0.7.2.
Changed
- The daemon is its own binary,
dockmad, installed next todockma(install.sh,make installand the release tarball ship both). Onlydockmadcarries the virtualization entitlement. The launchd job runs thedockmadbeside thedockmathat ranstart. After upgrading, rundockma restartonce: a job from an older dockma keeps running,dockma statusasks for the restart, and at its next launch (login or crash) it exits with the same hint. - The CLI talks to the daemon over XPC instead of
~/.dockma/control.sock, which is gone. Each side checks the other's code-signing identifier. While releases are ad-hoc signed, any local process can claim that identifier, as any of your processes can already usedocker.sock.dockma startno longer polls launchd or watches the state directory while the daemon comes up. During a stop,dockma statusreportsstopping(it saidstopped), anddockma startwaits for the stop to finish and then starts the VM, where it used to report that the daemon exited. dockma daemonno longer runs the daemon in the foreground: launchd hands the XPC service only to its job. To debug the daemon from its first instruction,DOCKMA_WAIT_FOR_DEBUGGER=1 dockma starthas launchd start it suspended until a debugger attaches.
Fixed
- The guest clock is synced as soon as the Mac fully wakes. The guest's clock stands still while the Mac sleeps; after a sleep shorter than 30 s it used to stay behind by the length of the sleep until the next 30 s sync.
- A guest that stops reading its control connection no longer freezes the daemon: a write to the agent that blocks for 5 s drops the connection, and the agent reconnects. Before,
dockma statusandstop, new docker.sock connections and published ports could all hang behind it. - The daemon applies the agent's messages in the order they were sent, so two quick port changes can't leave a stale set of forwarded ports.
- A
dockma stopthat arrives while the VM is starting no longer leaves the docker and shell sockets open during the shutdown. - The guest logs a full file-event queue once per overflow instead of once per dropped batch. Needs the new guest (
dockma install, ormake guest install-guest).