Repository navigation
Default instance with a launchagent created by start-at-login isn't available after startup #2252
Description
Activity
The
start-at-loginfeature generates aplistfile to autostart lima vm; it doesn't propagate variables or set up any docker-related things. ddev uses colima and colima uses lima under the hood.I guess is something going wrong with the VM itself at startup.
You can try to debug ddev docker with command:
# Output contextual details for the Docker provider ddev debug dockercheckThere are logs files under
~/.lima/default/launchd.stderr.logand~/.lima/default/launchd.stdout.logcould you provide those logs?it wasn't a ddev related problem, as i've shown in the second example in the issue summary i've also tried to directly run a docker command and no docker provider was available there neither:
$> docker ps Cannot connect to the Docker daemon at unix:///Users/rkoller/.lima/default/sock/docker.sock. Is the docker daemon running?and ddev isn't requiring colima, it is just still the recommended provider for macos. i've moved to using lima a few months ago instead of colima (since as you say colima is using lima under the hood anyway).
yesterday after the startup as well as after the shutdown and restart docker was not available (as illustrated in the issue summary). but the real odd thing is today is the first day docker was available right after i was starting my computer. nothing changed to before. taking a look at the two log files you've mentioned now,launchd.stderr.logliststime="2024-03-17T16:05:47+01:00" level=info msg="Using the existing instance \"default\"" time="2024-03-17T16:05:47+01:00" level=info msg="Starting the instance \"default\" with VM driver \"vz\"" time="2024-03-17T16:05:47+01:00" level=info msg="Running the host agent in the foreground" time="2024-03-17T16:50:10+01:00" level=info msg="Using the existing instance \"default\"" time="2024-03-17T16:50:10+01:00" level=info msg="Starting the instance \"default\" with VM driver \"vz\"" time="2024-03-17T16:50:10+01:00" level=info msg="Running the host agent in the foreground" time="2024-03-18T11:10:08+01:00" level=info msg="Using the existing instance \"default\"" time="2024-03-18T11:10:08+01:00" level=info msg="Starting the instance \"default\" with VM driver \"vz\"" time="2024-03-18T11:10:08+01:00" level=info msg="Running the host agent in the foreground"while
launchd.stdout.logis emptyAccording to
launchd.stderr.logthe instance was started properly every time. which is in line with the output forlimactl listwhere the vm was shown as running:$> limactl list NAME STATUS SSH VMTYPE ARCH CPUS MEMORY DISK DIR default Running 127.0.0.1:60022 vz aarch64 4 8GiB 100GiB ~/.lima/defaultbut yesterday on first start after setting up the login item as well as after shutting down and restarting aside the vm running docker was not available (not available when trying to run a ddev command as well as trying to run a docker command). and without changing anything docker is available after todays autostart.
i "think" i know now what the problem was/is. today i've got the following output right after i've logged in starting up the computer:
$> limactl list NAME STATUS SSH VMTYPE ARCH CPUS MEMORY DISK DIR default Stopped 127.0.0.1:0 vz aarch64 4 8GiB 100GiB ~/.lima/defaultthat was odd and unexpected. so i went brushing my teeth to give it some more time, and after returning about 5 to 10 minutes later i ran the command another time:
$> limactl list NAME STATUS SSH VMTYPE ARCH CPUS MEMORY DISK DIR default Running 127.0.0.1:60022 vz aarch64 4 8GiB 100GiB ~/.lima/defaultnow lima is shown as running and also docker was available. so it looks like and i "suppose" also on my previous attemps lima was actually properly started. but i "assume" like today it was just not completely ready yet finishing the startup process. might be the only problem that by creating a login item you have no feedback if lima has already completely successfully started up since the usual output on
limactl startis not output as a login item. i will observe the behavior over the next few days.Yes Lima takes a little while to start up so I suggest to fuggedaboutit.
Look at the log whatever log that is, I ams sure there is one.
When you find it why not write.a script to email you the log and then wherever you are and whatever you are doing after you finish brushing your teeth you will surely receive it!We've been working on reliable VM auto-start via LaunchDaemon on Intel Macs (QEMU/HVF, bridged networking via socket_vmnet). We hit several issues that together make unattended auto-start impossible without a wrapper around
limactl start. Sharing the recipe in case it helps others.Issues encountered:
-
IO-APIC timer kernel panic on Intel/HVF (Ubuntu and Debian intermittently fail to boot:
Kernel panic - not syncing: IO-APIC + timer doesn't work#84) — intermittent guest kernel panic at boot. Fix: addno_timer_check tsc=reliableto guest GRUB config. PR test.yml: useinject-cmdline-to-template.shto appendno_timer_checkkernel command line option #2541 applies this in CI but not in user-facing templates. -
socket_vmnet not verified after start (limactl start does not verify socket_vmnet succeeded, blocks forever on failure #5074) — Lima's
startDaemon()fires and forgets. Ifvmnet_start_interfacefails (VMNET_FAILURE), Lima starts QEMU anyway andlimactl start --foregroundblocks forever waiting for SSH. -
Stale hostagent state from unclean shutdown (limactl start fails with stale ha.sock/ha.pid from unclean shutdown #5075) — if the host shuts down before Lima's signal handler finishes cleanup, stale
ha.pid/ha.sockblock the nextlimactl startwith a fatal error. -
vmnet.framework dependency on
com.apple.NetworkSharing(limactl start does not verify socket_vmnet succeeded, blocks forever on failure #5074) — at early boot, the XPC Mach port may not be registered yet, causingvmnet_start_interfaceto return VMNET_FAILURE. Neither socket_vmnet nor Lima waits for this dependency.
Working recipe (LaunchDaemon wrapper):
The LaunchDaemon plist points at a wrapper script instead of
limactldirectly. The wrapper:- Validates prerequisites (sudo, limactl, socket_vmnet binary, Lima instance directory, log directory)
- Cleans stale hostagent and socket_vmnet state from prior unclean shutdown
- Polls for
com.apple.NetworkSharingXPC service readiness - Pre-starts socket_vmnet directly, polls for bridge100 or process exit, retries with backoff on failure (up to 3 attempts)
- Once socket_vmnet is confirmed running and bridge100 is up, execs
limactl start <vm> --foreground
Lima sees the pre-started socket_vmnet via its PID file and skips starting its own. The
execgives launchd clean lifecycle management of the hostagent process.This has been tested on two Intel Macs (i9, i7) with both clean and dirty (unclean shutdown) reboots. The VMNET_FAILURE is intermittent on one host (typically fails on the first attempt and succeeds on the second), but the retry handles it reliably.
The GRUB fix is baked into the VM provisioning template for new x86_64 VMs. Apple Silicon (VZ backend) is not affected by the IO-APIC panic.
-
Description
Yesterday I've tried the new start at login feature that got in with
0.21.0. Before i've shut down my computer yesterday I've used:`$> limactl start-at-login default
INFO[0000] The autostart file "/Users/rkoller/Library/LaunchAgents/io.lima-vm.autostart.default.plist" has been created or updated
When I've started my computer today and I tried to directly start a project in DDEV a framework for local development environments in docker i got:
When I checked if the lima instance is running:
My default instance was shown as running. I then did a
limactl stopdirectly followed by alimactl startand now docker was available to ddev. And if go into the macos system settings the lima login item is listed:When clicking the
ìicon that opens up a finder window:I've then retested, shut down my computer another time and started it up again. After that instead of trying to run a ddev command i tested with a plain docker command:
and again with
limactl listthe instance was shown as runningFor the context i am on a M1pro running macOS Sonoma 14.4 and limactl version 0.21.0 (using the docker template with vz and virtiofs). if you need more informations please let me know.