[Android/Termux] DSH 0.1.5-rc.1 无法运行：flock is not supported on android-arm64（附 sharp 问题与临时修复）

[MinX-Bangshe]

---

中文摘要

DSH 0.1.5-rc.1 在 Android/Termux（aarch64）上每一轮 agent 运行都会失败，界面报：

本轮运行失败  flock is not supported on android-arm64  UNKNOWN

原因：@deepseek-ai/dsh-session-persistence-jsonl 从 0.1.5 起在每个会话写入前要对 session.lock 取 POSIX flock，而 @deepseek-ai/node-addon-system/lib/flock.js 只支持 linux/darwin，其它平台直接抛 ERR_FLOCK_UNSUPPORTED_PLATFORM；没有 android-arm64 的原生绑定包。0.1.2 不使用 flock，因此这是 0.1.5 引入的回归。

同一升级还暴露第二个 Android 兼容问题：sharp 没有 android-arm64 预编译（需回退到 @img/sharp-wasm32）。

---

English report

Environment

• Device: Samsung SM-N986U (Galaxy Note 20 Ultra), Android 13
• Runtime: Termux 0.119.0-beta.3, Node.js v24.18.0（process.platform === 'android', process.arch === 'arm64'）
• DSH: 0.1.5-rc.1, installed globally via npm install -g @deepseek-ai/dsh
• Install path: $PREFIX/lib/node_modules/@deepseek-ai/dsh

Summary

Every agent turn fails on Android/Termux:

本轮运行失败 flock is not supported on android-arm64 UNKNOWN

The session JSONL is never materialized, so no session can run.

Steps to reproduce

1. Android (aarch64) + Termux, Node 24.
2. npm install -g @deepseek-ai/dsh@0.1.5-rc.1
3. dsh web --no-open, open the printed token URL, send any message.
4. The turn fails immediately with the error above.

Root cause

• @deepseek-ai/node-addon-system/lib/flock.js → loadBinding():

  const { platform, arch } = process;
  if (platform !== 'linux' && platform !== 'darwin') {
      throw Object.assign(new Error(`flock is not supported on ${platform}-${arch}`), {
          code: 'ERR_FLOCK_UNSUPPORTED_PLATFORM',
          syscall: 'flock',
      });
  }

  Android reports platform === 'android', so it always throws.

• There is no @deepseek-ai/node-addon-system-android-arm64 package; only node-addon-system-darwin-arm64 (and the linux variants) ship prebuilds.

• Consumer: @deepseek-ai/dsh-session-persistence-jsonl → SessionWriteLease.acquire() calls tryLockExclusive(handle.fd) on session.lock for every write-open. It maps EAGAIN to SessionAlreadyOwnedError and rethrows everything else — so ERR_FLOCK_UNSUPPORTED_PLATFORM becomes a fatal turn error.

• Regression: 0.1.2's dsh-session-persistence-jsonl does not import flock at all, so Android worked before this upgrade.

Suggested fix (upstream)

Any of these is fine; the lock exists to serialize cross-process writers, and on a single-process harness an in-process claim already excludes all writers (the module's own docs note the browser worker stubs flock to immediate success for exactly this reason):

1. Degrade gracefully: on an unsupported platform, treat the lease as acquired (optionally warn once), instead of throwing.
2. Ship/allow an android-arm64 binding (Termux can build src/flock.c with node-gyp), and gate the platform check on actual binding availability rather than a hard platform allow-list.
3. Make SessionWriteLease capability-based (e.g. skip the kernel lock when no binding is available).

Workaround (what we applied locally)

Patch the platform branch in .../@deepseek-ai/node-addon-system/lib/flock.js:

if (platform !== 'linux' && platform !== 'darwin') {
    binding = { tryLock: (_fd, cb) => cb(0) };   // single-process harness: emulate acquired lock
    return binding;
}

Verified: tryLockExclusive(0) resolves, and sessions run again.

Second Android issue on the same upgrade: sharp

sharp has no android-arm64 prebuilt, so image/attachment handling needs the WASM fallback. Workaround used: copy @img/sharp-wasm32@0.35.4 (+ @emnapi/runtime, tslib) into sharp/node_modules, then sharp reports versions.sharp 0.35.4 / vips 8.18.6.

Minor

Starting a second dsh web while one is already listening produces EADDRINUSE 127.0.0.1:3080 and a full stack trace. A clearer message ("already running on port 3080") would help.

Note

Both workarounds are wiped by npm install -g @deepseek-ai/dsh (they live inside node_modules) and must be re-applied after every upgrade. If DSH can carry these Android accommodations itself, Termux users would stop hitting a hard failure on upgrade.

[maxwell-feng]

补充确认，供定位参考（信息都并入此帖，不再另开）：

1) 该问题在最新的 0.1.6-alpha.1（commit 0d1f50007f，今天从 master 构建）上依然存在，未被修复。

• 环境：Android 16 两台设备（23113RKC6C、XT2507-5）+ Termux + Node v26.4.0（process.platform === 'android'、process.arch === 'arm64'）+ pnpm 11.7.0，源码检出方式（pnpm install && pnpm run build && pnpm dsh web）。
• flock.ts、build.ts、lease.ts 在上述两个版本之间逐字节相同（git diff c291e7961a..master 为空），因此 0.1.6 没有触及这条路径。
• 顺带把时间线补精确一点：会话租约要求内核 flock 是 c58097a826（8/31，当时用 fs-ext），把实现换成 @deepseek-ai/node-addon-system 是 d927cbff99（9/7）。

2) 走源码检出时，只放宽加载器的平台判断还不够。 native/system/scripts/build.ts:27 有同样的 platform !== 'linux' && platform !== 'darwin' 判断，在 Termux 下直接跳过，所以 find native -name '*.node' 为空——源码路径上没有任何产物。也就是说源码检出需要同时满足：(a) 放宽闸门，(b) 能本地构建出 bionic 可加载的 .node；只做 (a) 会从“平台不支持”变成“找不到 binding”的另一条错误。npm 全局安装路径能靠上面的 stub 绕过，是因为它只需要 JS 层不再抛错。

3) 一个便于确认的现场特征： 失败时 session 目录里会留下空的 session.lock（open 先于 flock 建立该文件），而 session.jsonl.zstd 不再更新；只读路径（列目录、读历史）不碰锁，不受影响。实测最后一次真实会话日志早于上述改动，之后只剩 lock 残留。

最小复现（源码检出，无需启动 UI）：

cd packages/session/session-persistence-jsonl
node -e "import('@deepseek-ai/node-addon-system/flock').then(m => m.tryLockExclusive(0)).then(() => console.log('ok')).catch(e => console.log(e.code, '|', e.message))"
# ERR_FLOCK_UNSUPPORTED_PLATFORM | flock is not supported on android-arm64

[zexadev]

中文摘要: Android 上这条其实不必等原生构建——koffi 已经在 dsh 自己的依赖树里——需要这把锁的 dsh-session-persistence-jsonl 自身就依赖它,且有 android-arm64 预编译,所以在平台闸上加一条 android 分支、经 koffi 调 libc 的 flock(2) 就能跑通,不新增依赖、不需要 node-gyp。下面是实现、一个容易踩的 errno 约定,以及为什么不该用「空实现直接成功」了事。

---

The diagnosis in this thread matches what we see; one thing that hasn't come up yet is that Android doesn't actually need a native build to be unblocked.

bionic has flock(2) — only the binding package is missing

@deepseek-ai/node-addon-system-linux-arm64, -linux-x64 and -darwin-arm64 are all published at 0.1.2; @deepseek-ai/node-addon-system-android-arm64 doesn't exist. The loader in node-addon-system/lib/flock.js gates on platform !== 'linux' && platform !== 'darwin' and throws before any of that matters. The syscall itself is there in bionic, so an android-arm64 build of the existing addon would be enough on your side.

A runtime branch needs no new dependency

@deepseek-ai/dsh-session-persistence-jsonl already declares koffi: ^3.1.0 among its own dependencies — the very package that needs the lock — and so do dsh-fs-local, dsh-subprocess-local, dsh-host-directory-picker-native and dsh-sandbox-windows-acl. koffi ships prebuilt android-arm64 binaries, and they are already present in an Android install: @koromix/koffi-android-arm64/android_arm64/koffi.node is sitting in the tree we bundle, pulled in by dsh's own dependencies, not added by us. So the platform gate can take another route on Android without touching the dependency list:

const koffi = createRequire(import.meta.url)('koffi')
const flock = koffi.load('libc.so').func('int flock(int fd, int operation)')
// LOCK_EX | LOCK_NB
const rc = flock(fd, 2 | 4)
callback(rc === 0 ? 0 : koffi.errno())

The errno convention is the part that costs an hour if you get it wrong. The callback takes 0 for success and a positive errno for failure; the caller negates it before handing it to getSystemErrorName. Return a negative errno from here and that negation makes it positive, and getSystemErrorName throws ERR_OUT_OF_RANGE — which surfaces as a confusing error that has nothing to do with locking.

Why not stub it to always succeed

The obvious shortcut is to make Android skip locking entirely. We didn't, because the failure mode is silent and lands on the user's session log: two writers both believe they hold the lease and interleave appends. On a phone there is normally exactly one dsh process, so the shortcut would hold today — but if it ever stops holding, the damage is corrupted session history, and going through libc costs nothing to avoid that. Semantics match the native addon: LOCK_EX|LOCK_NB, 0 when the lock is taken, EAGAIN when someone else holds it, contention decided by the caller from the errno.

Where this is running

Shipped in an Android app (unrooted, no Termux) since our 0.1.15, against dsh 0.1.5-rc.2, as a build-time patch to the runtime we bundle. The patcher requires the platform gate to match exactly once and fails the build otherwise, so a change on your side shows up immediately.

Implementation: scripts/android-flock-shim.mjs

(Separately, the hard-link EACCES that Android apps hit in the persistence layer is still open — I've added a current call-site audit and the AOSP sepolicy citation to #487.)