OrbStack Won't Start: Fixing 'vmgr is already running (socket)'

I publish various services from my home server with Docker, so when OrbStack (Docker) does not work properly it seriously disrupts my daily work and my use of those services.
This time, when I tried to start OrbStack on macOS, not only did the Docker containers fail to come up, the app itself did not launch at all and quit immediately, which made me quite nervous.
Here I record how I investigated the cause and recovered.

OrbStack’s Host exit diagnostics showed the following.

reason: failed to start
raw wait status: 256 (0x00000100)
raw flags: 0x86000000
exit detail: none

Only this single line was recorded in vmgr.log.

🌲 vmgr | time="07-28 05:18:17" level=fatal msg="vmgr is already running (socket)"

Reading the error message at face value, it says “vmgr sees that its own socket exists and concludes that another instance is already running”. However, OrbStack itself was down and Docker was completely unusable, so I could not take it literally.

Environment

Investigation

1. First, check what processes actually exist

Doubting the words “already running”, I used ps to check whether a vmgr process was really running.

ps aux | grep -i -E "orbstack|vmgr" | grep -v grep

As a result, the following process already existed.

user  644  ... 3740:13.12  OrbStack Helper vmgr -build-id 1780592975 -handoff

2. Check how long this process has been alive

Now that I knew the PID, I checked its start time and elapsed time.

ps -p 644 -o pid,lstart,etime,command

PID STARTED                    ELAPSED    COMMAND
644 土 7/11 13:03:18 2026      16-16:18:01 ... vmgr -build-id 1780592975 -handoff

It was a process that had been running for more than 16 days and 16 hours. That makes it clear this was a survivor of an older session, separate from the new OrbStack I was trying to start.

3. Check whether it is managed by launchd

OrbStack’s helper processes are supposed to have their lifecycle managed by launchd, so I checked just in case.

launchctl list | grep -i orbstack

The result was empty. In other words, this vmgr process had become an isolated process (an orphan) outside of launchd’s management. My guess is that the link to its parent process was broken during an OrbStack update or a sleep/wake cycle, and it was never terminated, so it kept running.

4. Check where the socket files are

ls -la ~/.orbstack/run/

Under ~/.orbstack/run/ there were several socket files such as vmcontrol.sock, and the old vmgr process was still holding on to them. That settled the sequence of events: when the new OrbStack started, it looked at those sockets, falsely detected that it was “already running”, and exited immediately with fatal.

Cause

For some reason, OrbStack’s helper process (vmgr) had come loose from launchd’s management, become orphaned, and survived for more than 16 days while still holding the socket files under ~/.orbstack/run/. When the new OrbStack started, vmgr detected that its own socket was already in use and, even though no working instance actually existed, decided it was “already running” and refused to start.

Steps to fix it

The PID of the orphaned old vmgr process was already known from steps 1 and 2 of the investigation (644). First I tried a normal kill.

kill 644

It did not exit even after waiting several seconds, and the process stayed alive. Force it to terminate with kill -9.

kill -9 644

Confirm that the process is gone.

ps -p 644 -o pid,command

Restart OrbStack.

open -a OrbStack

I confirmed that a new vmgr process started, that no error appeared in vmgr.log, and that orb status returned Running, and treated that as resolved.

orb status
# => Running

The new vmgr process (with a different PID) started normally, and I could confirm that Docker’s network bridge and port forwarding were also written to the log normally. OrbStack has been usable without problems ever since.

What I learned and what to do from now on

• When OrbStack “fails to start”, the app itself is not necessarily broken; there are cases where an old helper process is simply sitting there and getting in the way of the new startup
• When OrbStack-related processes do not appear in launchctl list but do appear in ps aux, that is a strong sign of an orphaned process
• If the same symptom keeps recurring, the helper may not be restarting correctly after an OrbStack app update, so consider a clean restart or reinstall of the whole helper set (including dev.orbstack.OrbStack.privhelper)

Summary

The error “vmgr is already running (socket)” looks like a warning about a duplicate launch if you only read the words, but this time it was a case where an old helper process that had come loose from launchd’s management kept running and holding the socket. Cross-check ps aux against launchctl list to identify the orphaned process, clean it up with kill -9, and restart, and it recovers.

I hope this helps someone troubled by the same symptom.

See also