Repository navigation
Colima daemon #262
Description
Activity
+1
It would be really nice to be able to start colima with launchctl and brew services.
I am interested in taking this on but curious about what the end result might look like.
The simple path forward is a Colima process per vm, most configurations are likely to only have one and this is how qemu operates. I would think the IPC surface for this is minimal and just operating like detach mode as docker does.
Meaning, do not attach user stdout/stdin/stderr.
The result is a process to only supervise the qemu process spawned.Taking some inspiration from this library, https://pkg.go.dev/github.com/sevlyar/go-daemon?utm_source=godoc.
Not taking the dependency on the library, unless that is okay?Or is there a desire for this to introduce a true daemon that manages all Colima instances?
Thoughts?
I spent some time this weekend and got to what I would consider a draft PR.
However, this same library is used to launch a few other daemons, and I don't believe this nesting will work.
Qemu exits after complaining about missing the gvproxy domain socket?
Definitely looks a lot like this.
sevlyar/go-daemon#82@jbreiding my bad! I actually composed a response but just realised I didn't send it.
You do not need to worry about background daemons btw, and it is not needed in this case.I am working an
autostartconfig for the VM, as well a newstart-allcommand.
In essence all that will be required to start all VMs will becolima start-all --filter=autostart=trueThe only thing left would be a user launchd file that will include the above command.
Reacted by Jeremy, Frankie and Chinmay Pendharkar@abiosoft no worries at all, it was a nice little weekend adventure.
btw, do you use vscode for debugging? If you do would you mind sharing the debug configuration?
I see the
.gitignoreignores this folder and I had a painful time launching with debug to troubleshoot what was happening with the daemon process.Looks like the work for a service with brew can be leveraged from here.
#96Hello,
Is there any news regarding this issue?
On my system, the drives can take up to a minute to mount at boot, so it would be useful to be able to start colima as a launchd service to wait until the mounting is done.The simple path forward is a Colima process per vm
This would be fine, as I don't necessarily want to start all of the ones I have.
Commands like:
colima launchagent [profile] [flags]with flags possibly including--user(plist in~/Library/LaunchAgents, start on login, stop on logout) or--system(plist in/Library/LaunchAgents, same but for applies to all system users)colima launchdaemon [profile] [flags]with flags possibly including--system(plist in/Library/LaunchDaemons) but not--user; kinda redundant though.
Or alternatively a more OS-independent
servicecommand made for easy integration (likecompletionphilosophically is):colima service [profile] [--launchagent | --launchdaemon | --systemd] [--user | --system]For macOS although orthogonal, it would need this possible sandboxing issue to be solved: #490
I noted that there's a Homebrew LaunchDaemon that appears to have worked at some point. Dunno if it works lately (not a Homebrew user).
I opened an issue at
nix-darwin: nix-darwin/nix-darwin#1182This current issue would still be useful for users that are not using
nix-darwinthough.I am working an autostart config for the VM, as well a new start-all command.
colima start-all --filter=autostart=true@abiosoft in that case there would only be one plist/launchdaemon; I believe it is still interesting to be able to have them individually handled:
- no need for a setting
- they are separately monitored and integrated into the native service manager (e.g auto restart, stdout/err logs,
systemctl status <service>.service/launchctl print <service> | grep 'job state')
As for the
start-allcommand, is it necessary? That feels like special-casing thestartcommand:colima start # the default profile only colima start <profile> # the `<profile>` one only colima start <profile1> <profile2> <profile3> # all three of these, explicitly colima start --filter=autostart=true # any VM that match the filter colima start --filter=false # allOf course
--foregroundand--filtermay be made incompatible.To further clarify, I think both a
serviceand a "startmany" commands can be useful.- added 2 commits that reference this issue
on Sep 12, 2026
Currently we always have to manually start colima when starting our macbook, however it would be nice to have it as a daemon so that it can start automatically. Is there any reason why this has not been done yet?