Summary
After systemctl restart aenv, the first sandbox start reliably fails with:
ublk-daemon.sock: No such file or directory
Restarting the service a second time clears it, and subsequent starts work normally. It looks like a socket-unlink race between the outgoing daemon and the incoming one rather than a configuration problem, but the failure surfaces as a confusing "file not found" at sandbox-create time rather than at service start.
Filing this because we have hit it consistently enough to write "if this happens, restart once more" into our own runbook, and that felt like something upstream would rather know about than have operators quietly work around.
Environment
- AgentENV v0.1.1, built from source
- Ubuntu 26.04, systemd-managed
aenv.service, non-root service account with KVM access via supplementary group
- Reproduces on a single-node install
Reproduction
systemctl restart aenv- Immediately:
aenv start -d --timeout 600 ubuntu
- First attempt fails with the error above
systemctl restart aenv again- Same start command now succeeds
The timing window matters — if enough time passes between the restart and the first start, we do not see it. That is what makes us think it is a race on the socket path rather than a persistent state problem.
What we have not done
We have not instrumented the daemon to confirm the ordering, so "socket-unlink race" is inference from the symptom and the timing sensitivity, not something we have proven. Happy to gather more if it would help — journal excerpts around the restart, strace on the daemon, or a tighter reproduction script.
Why it is worth fixing even though the workaround is trivial
The workaround is a second restart, so the operational cost is low. The reason to fix it is that the error names a socket path, which sends operators looking for a missing file or a permissions problem in their own install rather than at a startup ordering issue. Either waiting for the socket to be ready before accepting sandbox creates, or returning a "daemon still starting" error rather than a filesystem error, would remove that dead end.
Related but distinct from the existing ublk issues (#93 kernel warnings, #130 kernel 6.6 zero-copy) — this one is about restart ordering, not kernel support.
Summary
After
systemctl restart aenv, the first sandbox start reliably fails with:Restarting the service a second time clears it, and subsequent starts work normally. It looks like a socket-unlink race between the outgoing daemon and the incoming one rather than a configuration problem, but the failure surfaces as a confusing "file not found" at sandbox-create time rather than at service start.
Filing this because we have hit it consistently enough to write "if this happens, restart once more" into our own runbook, and that felt like something upstream would rather know about than have operators quietly work around.
Environment
aenv.service, non-root service account with KVM access via supplementary groupReproduction
systemctl restart aenvaenv start -d --timeout 600 ubuntusystemctl restart aenvagainThe timing window matters — if enough time passes between the restart and the first start, we do not see it. That is what makes us think it is a race on the socket path rather than a persistent state problem.
What we have not done
We have not instrumented the daemon to confirm the ordering, so "socket-unlink race" is inference from the symptom and the timing sensitivity, not something we have proven. Happy to gather more if it would help — journal excerpts around the restart, strace on the daemon, or a tighter reproduction script.
Why it is worth fixing even though the workaround is trivial
The workaround is a second restart, so the operational cost is low. The reason to fix it is that the error names a socket path, which sends operators looking for a missing file or a permissions problem in their own install rather than at a startup ordering issue. Either waiting for the socket to be ready before accepting sandbox creates, or returning a "daemon still starting" error rather than a filesystem error, would remove that dead end.
Related but distinct from the existing ublk issues (#93 kernel warnings, #130 kernel 6.6 zero-copy) — this one is about restart ordering, not kernel support.