pandoc --pdf-engine fails with "openFile: resource busy (file is locked)" on deployed Containers — the tutorial's PDF flow cannot work in production

[mjaskolski]

Summary

The PDF-conversion flow the tutorial documents (pandoc card.md -o card.pdf --pdf-engine=typst) fails on real, deployed Cloudflare Containers with:

pandoc: openFile: resource busy (file is locked)
HasCallStack backtrace:
  bracket, called at ./System/IO/Temp.hs:114:3 in temporary-1.3-…:System.IO.Temp

The same command works under wrangler dev (local Docker), so the failure is invisible until first deploy. The trigger is narrow: it is specifically the --pdf-engine path's temp-file staging (System.IO.Temp / the temporary package, i.e. GHC's file locking on the temp file). Plain pandoc output files and ordinary shell writes to the same filesystem are fine.

Reproduction

examples/container from this repo at 76d9e75, deployed unmodified except for two Dockerfile changes: computerd tag bumped to 0.1.1 (to match the published @cloudflare/computer@0.1.1 the example was installed with), and pandoc 3.10.1 + typst 0.15.1 added to the image (same tools the tutorial uses). wrangler 4.119, instance type standard-2.

All probes are plain curl against the deployed example's own HTTP surface:

Control — the filesystem accepts writes (shell):

POST /c/repro1/exec {"command":"sh -c 'echo ctrl > /tmp/ctrl.txt && cat /tmp/ctrl.txt'"}
→ {"status":"completed","exitCode":0,"stdout":"ctrl\n"}

Control — plain pandoc output file works (no engine involved):

POST /c/repro1/exec {"command":"printf \"# hi\\n\" | pandoc -f markdown -t docx -o /tmp/out.docx -"}
→ {"status":"completed","exitCode":0}

Failure — any --pdf-engine invocation, container-local /tmp:

POST /c/repro1/exec {"command":"printf \"# hi\\n\" | pandoc -f markdown -o /tmp/out.pdf --pdf-engine=typst -"}
→ {"status":"failed","exitCode":1,"stderr":"pandoc: openFile: resource busy (file is locked)\nHasCallStack backtrace:\n  bracket, called at ./System/IO/Temp.hs:114:3 …"}

Failure — the tutorial's exact flow (input written host-side, synced to the mount — note pushed: 2, sync itself works fine):

PUT  /c/repro1/file/workspace/card.md  ("# Karta…")
POST /c/repro1/exec {"command":"pandoc /workspace/card.md -o /workspace/card.pdf --pdf-engine=typst"}
→ {"status":"failed","exitCode":1,"stderr":"pandoc: openFile: resource busy (file is locked)…","pushed":2,"sync":{"status":"complete","applied":3}}

Analysis

GHC takes an fcntl lock when System.IO.Temp opens the temp file that the --pdf-engine path stages the intermediate document into, and the deployed Container filesystem refuses that lock (EBUSY-shaped failure surfaced as "resource busy (file is locked)"). Local Docker's filesystem grants the lock, hence the dev/prod split. Ordinary openFile for pandoc's --output does not trip it (the docx control above), so the blast radius is exactly "anything that goes through pandoc's PDF-engine temp staging".

Working workaround (verified on the same deployment)

Skip --pdf-engine entirely: have pandoc emit standalone typst markup to stdout (shell owns the file), then compile with typst (Rust — no GHC locking):

POST /c/repro1/exec {"command":"printf \"# hi\\n\" | pandoc -f markdown -t typst -s - > /tmp/x.typ && typst compile /tmp/x.typ /tmp/x.pdf && ls -la /tmp/x.pdf"}
→ {"status":"completed","exitCode":0,"stdout":"-rw-r--r-- 1 root root 7004 … /tmp/x.pdf\n"}

Possibly worth a note in the tutorial until the underlying lock behavior is addressed on the Containers filesystem — as-is, the tutorial's flagship command works in every local run and fails on the first production deploy, which is an expensive way to find out.

Happy to provide the deployed-example wrangler config or run further probes if useful.

[3x3xX3N0N]

Possible cause: use_ino + ino: 0 colliding in GHC's lock table

Not a reproduction — I can't hit this locally, since wrangler dev falls back to the userspace shim rather than kernel FUSE. But the error string is a GHC runtime message, and GHC's RTS keys its file-lock table on (st_dev, st_ino) rather than using OS locks, so two files reporting the same inode look to it like one file already open for writing.

computerd mounts with use_ino, which packages/computerd/src/fuse/options.ts:18-20 documents as telling "the kernel to trust the inode numbers returned by getattr". Two getattr paths can return zero:

• packages/computerd/src/fuse/driver.ts:332 — staged files report ino: 0 while pendingCreate is true (:229, "true until the first spill creates the VFS inode")
• packages/computerd/src/fuse/driver.ts:1072 — ino: stat.ino ?? 0 whenever the VFS supplies no inode

Newly created output files are exactly the pendingCreate case, so a pandoc run writing more than one new file under the mount would present the kernel with several distinct files all at inode 0.

Cheap test: set COMPUTERD_FUSE_USE_INO=0 (options are opt-out per the same file) and re-run. If the lock error disappears, the fix is unique inode numbers on the staged path rather than anything pandoc-specific. Note the tradeoff — that same comment says use_ino "is required for hardlinks to stat as the same inode."

Separately: computerd implements no getlk/setlk/flock, so any tool relying on real POSIX record locking will behave differently here regardless.

Read against 76d9e75.

[3x3xX3N0N]

Following up on my own comment — I should have engaged your fcntl reading directly rather than posting an alternative beside it.

Having re-read your analysis: I think the mechanism is GHC's RTS lock table (rts/FileLock.c) rather than an fcntl lock. That table is process-local and keyed on (st_dev, st_ino), and "resource busy (file is locked)" is its characteristic message — it's the same error you get opening one file twice for writing inside a single GHC process, with no OS lock involved.

What makes me prefer it is your own strongest clue, the dev/prod split. An fcntl explanation has to account for why local Docker grants a lock that the deployed Container refuses. The inode reading explains it without that step: wrangler dev falls back to computerd's userspace shim, while deployed Containers get real kernel FUSE with use_ino — and use_ino is precisely the flag that makes the kernel trust the ino: 0 that staged files report (packages/computerd/src/fuse/driver.ts:332). Two temp files at inode 0 collide in the RTS table; one filesystem trusts the number, the other never gets asked.

It also fits the narrowness you identified. System.IO.Temp stages two paths (the temp file plus the output), while --output alone touches one — so only the PDF-engine path can collide, which is exactly the blast radius you measured.

Stating the discriminator plainly, since either of us may be wrong: run the failing command on a deployed Container with COMPUTERD_FUSE_USE_INO=0. If it succeeds, it's inode collision in the RTS table. If it still fails, the inode theory is dead and your fcntl reading stands — computerd implements no getlk/setlk/flock at all, so a real lock request has nothing to land on.

Your typst workaround sidesteps both, since it takes GHC out of the path entirely.

Read against 76d9e75.