Daytona创建快照失败：无可用运行器错误

Daytona 错误日志分析：Failed to get initial runner 问题排查

先来看具体现象：SnapshotManager 每隔10秒就会抛出一条 WARN 级别的日志，内容是“Failed to get initial runner: Error: No a vailable runners”。乍一看像是严重故障，但注意级别是 WARN，非致命错误，系统会反复重试。这类日志通常表明资源分配遇到临时障碍，需要深入分析根本原因。

错误日志详情

{"level": 40, // WARN 级别（非致命错误）"context": "SnapshotManager","msg": "Failed to get initial runner: Error: No a vailable runners"}

这条日志来自 SnapshotManager 的定时同步任务，每10秒精准复现一回。这种周期性报错提示系统正在持续尝试分配 runner，但始终无法满足条件。

根本原因分析

问题其实不复杂——a vailabilityScore 阈值没达标。换句话说，系统试图为一条 pending 状态的 snapshot 分配初始 runner，但现有的 runner 分数不够，被过滤掉了。简单来说，就是阈值设置过高，导致符合条件的 runner 不足。

来看数据库里的记录：

snapshot	name	state	sandboxClass	initialRunnerId
0e5a7b23...	sandbox-extra:0.6	pending	container	(空，未分配)

SnapshotManager 在 handleSnapshotStatePending() 中尝试为它分配 runner，关键逻辑在这里（snapshot.manager.ts:1210-1216）：

const a vailabilityThreshold =this.configService.getOrThrow('runnerScore.thresholds.a vailability') +// 默认 10this.configService.getOrThrow('runnerScore.thresholds.initialRunnerScoreAddon')// 默认 20initialRunner = await this.runnerService.getRandomA vailableRunner({regions: ['us'],sandboxClass: 'container',a vailabilityScoreThreshold: a vailabilityThreshold,// = 10 + 20 = 30...})

而数据库里唯一的 runner 是这样的：

name	state	region	sandboxClass	a vailabilityScore
default	ready	us	container	5

findA vailableRunners() 里的过滤条件要求：

a vailabilityScore: MoreThanOrEqual(a vailabilityThreshold)// 要求 >= 30

runner 的 a vailabilityScore = 5，离 30 的阈值差了一大截，自然被无情过滤掉，返回空数组，最终抛出 No a vailable runners。这是导致报错的核心直接原因。

原因总结

把整个过程串起来看：

┌─────────────────────────────────────────────────────┐│Snapshot (pending) 需要初始 runner││要求: a vailabilityScore >= 30 ││(a vailability阈值10 + initialRunnerScoreAddon 20) ││ ││唯一 Runner: a vailabilityScore = 5❌ 不满足 ││ ││结果: "No a vailable runners" → 每10秒重试 │└─────────────────────────────────────────────────────┘

这里 a vailabilityScore 是一个动态计算的负载评分，基于 CPU、内存、磁盘使用率等，分数越低代表 runner 越空闲。但 initialRunnerScoreAddon 额外加了20分的门槛，目的是确保 snapshot 构建只分配到足够空闲的 runner，避免影响已有任务。这个设计本意是好的，但在开发环境只有一台 runner 且负载较高时，就容易出现这种尴尬局面。简单来说，就是评分机制与单节点环境不兼容。

可能的解决方案

遇到这种情况，有几种应对思路，按推荐程度排列：

方案 1：降低阈值（推荐，适合开发环境）

直接修改 docker-compose.yaml，为 API 容器添加环境变量，把额外门槛去掉或降低基数：

environment:- RUNNER_INITIAL_RUNNER_SCORE_ADDON=0# 取消额外门槛（默认20）# 或- RUNNER_A VAILABILITY_SCORE_THRESHOLD=0# 直接降低基础门槛

方案 2：手动更新 runner 的 a vailabilityScore

临时性的快速修复，直接改数据库把分数调高：

UPDATE runner SET "a vailabilityScore" = 100 WHERE name = 'default';

方案 3：删除卡住的 pending snapshot（如果不需要）

如果那条 snapshot 已经无关紧要，直接清理数据：

DELETE FROM snapshot_region WHERE "snapshotId" = '0e5a7b23-82dd-4fba-abfb-890dcfe754f6';DELETE FROM snapshot WHERE id = '0e5a7b23-82dd-4fba-abfb-890dcfe754f6';

方案 4：检查 runner 上报机制

a vailabilityScore 只有5，说明 runner 上报的资源信息偏低。可以翻一翻 runner 容器的日志，看它是否正确上报了 CPU、内存等数据：

docker logs daytona-runner-1 --tail 50

这几种方案各有适用场景，开发环境通常推荐方案1，最直接有效。生产环境则要根据实际情况权衡，不建议贸然降低阈值，最好先确认 runner 资源是否真的饱和。通过合理调整阈值或检查资源上报，可以快速解决"Failed to get initial runner"错误。