error out when run_vminitd.sock path length is too long#89
error out when run_vminitd.sock path length is too long#89dmcgowan merged 1 commit intocontainerd:mainfrom
Conversation
There was a problem hiding this comment.
Pull request overview
This PR addresses a macOS-specific issue where UNIX socket paths exceeding 104 characters cause VM startup failures without clear error messages. The change adds explicit validation to detect overly long socket paths before attempting to start the VM, providing users with a clear error message instead of a generic timeout.
Changes:
- Added pre-emptive validation for socket path length on macOS
- Added explanatory comments about the macOS socket path limitation and failure symptoms
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
|
LGTM on this change, did something else change to cause the calculation to differ or use a different cwd? |
|
We should probably just ditch the state directory in the vm instance and use cwd. If we need to support multiple VMs in the future, we can add an identifier which just gets added in the .sock file name |
akerouanton
force-pushed
the
unix-path-limit
branch
from
b6f90a5 to
f9e11a0
Compare
UNIX socket path is limited to 104 characters (including \0) on macOS and 108 on Linux and Windows. To circumvent this limitation, vmInstance.Start() tries to compute the relative path to the run_vminitd.sock. However, if the bundle path points to a symlinked directory, this relative path may contain many double-dots and the full path, exceeding the limit. This is the case if containerd state dir is in /tmp (which is symlinked to /private/tmp on macOS). In that case, nothing fails explicitly. It appears as if the VM failed to start, whereas the log show that vminitd executed successfully. The only error logged is: Timeout while waiting for VM to start. Detect if the socket path is too long before trying to start the VM, and return an explicit error. Signed-off-by: Albin Kerouanton <albin.kerouanton@docker.com>
akerouanton
force-pushed
the
unix-path-limit
branch
from
f9e11a0 to
058eec4
Compare
There was a problem hiding this comment.
Pull request overview
Copilot reviewed 1 out of 1 changed files in this pull request and generated no new comments.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
No it was just caused by running some integration tests in |
3 participants
On macOS, UNIX socket path is limited to 104 characters (including \0). To circumvent this limitation, vmInstance.Start() tries to compute the relative path to the run_vminitd.sock. However, if the bundle path points to a symlinked directory, this relative path may contain many double-dots and the full path, exceeding the limit. This is the case if containerd state dir is in /tmp (which is symlinked to /private/tmp on macOS).
In that case, nothing fails explicitly. It appears as if the VM failed to start, whereas the log show that vminitd executed successfully. The only error logged is: Timeout while waiting for VM to start.
Detect if the socket path is too long before trying to start the VM, and return an explicit error.