[GH-ISSUE #158] First sandbox start after 'systemctl restart aenv' fails with ublk-daemon.sock: No such file or directory #53

New issue

Closed

opened 2026-10-29 14:18:53 +00:00 by bsakaguchi · 0 comments

bsakaguchi commented

2026-10-29 14:18:53 +00:00

Owner

Originally created by @sunkencity999 on GitHub (Aug 11, 2026).
Original GitHub issue: https://github.com/kvcache-ai/AgentENV/issues/158

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.

Originally created by @sunkencity999 on GitHub (Aug 11, 2026). Original GitHub issue: https://github.com/kvcache-ai/AgentENV/issues/158 ### 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 1. `systemctl restart aenv` 2. Immediately: `aenv start -d --timeout 600 ubuntu` 3. First attempt fails with the error above 4. `systemctl restart aenv` again 5. 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.

bsakaguchi closed this issue

2026-10-29 14:18:53 +00:00

bsakaguchi referenced this issue

2026-10-29 14:20:08 +00:00

[PR #53] [CLOSED] feat(api): render server OpenAPI from tag-based templates #142