The first dispatch failed at the wait step with nothing to act on. The run logs showed the dind service container was never created — no service startup output at all, and teardown reporting "No such container" for the ID it had recorded — which is what act_runner does when it refuses a privileged container.
From the failing step, that is indistinguishable from dockerd simply being slow, so the step now says which one it is: if the service host resolves, the container exists and dockerd is not serving plain TCP on 2375; if it does not resolve, the service never started and the runner needs container.privileged.
Also raises the wait from 30s to 90s. The NAS took the full 30s before failing, so the old ceiling was too close to the observed time to distinguish slow from broken.
The docker CLI fallback is retained: the runner image has no docker binary, and the static install worked.
The first dispatch failed at the wait step with nothing to act on. The run logs showed the dind service container was never created — no service startup output at all, and teardown reporting "No such container" for the ID it had recorded — which is what act_runner does when it refuses a privileged container.
From the failing step, that is indistinguishable from dockerd simply being slow, so the step now says which one it is: if the service host resolves, the container exists and dockerd is not serving plain TCP on 2375; if it does not resolve, the service never started and the runner needs container.privileged.
Also raises the wait from 30s to 90s. The NAS took the full 30s before failing, so the old ceiling was too close to the observed time to distinguish slow from broken.
The docker CLI fallback is retained: the runner image has no docker binary, and the static install worked.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
The first dispatch failed at the wait step with nothing to act on. The
run logs showed the dind service container was never created — no service
startup output at all, and teardown reporting "No such container" for the
ID it had recorded — which is what act_runner does when it refuses a
privileged container.
From the failing step, that is indistinguishable from dockerd simply
being slow, so the step now says which one it is: if the service host
resolves, the container exists and dockerd is not serving plain TCP on
2375; if it does not resolve, the service never started and the runner
needs container.privileged.
Also raises the wait from 30s to 90s. The NAS took the full 30s before
failing, so the old ceiling was too close to the observed time to
distinguish slow from broken.
The docker CLI fallback is retained: the runner image has no docker
binary, and the static install worked.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
The first dispatch failed at the wait step with nothing to act on. The run logs showed the dind service container was never created — no service startup output at all, and teardown reporting "No such container" for the ID it had recorded — which is what act_runner does when it refuses a privileged container.
From the failing step, that is indistinguishable from dockerd simply being slow, so the step now says which one it is: if the service host resolves, the container exists and dockerd is not serving plain TCP on 2375; if it does not resolve, the service never started and the runner needs container.privileged.
Also raises the wait from 30s to 90s. The NAS took the full 30s before failing, so the old ceiling was too close to the observed time to distinguish slow from broken.
The docker CLI fallback is retained: the runner image has no docker binary, and the static install worked.
Co-Authored-By: Claude Opus 5 (1M context) noreply@anthropic.com