Hacktoberfest 2026: die Issues, die Maintainer für den Oktober markiert haben – offen und einsteigerfreundlich. Hacktoberfest-Issues durchsuchen

[Bug]: flock() on a mounted volume hangs forever (mount is missing `nolock`)

Offen Anfängerfreundlich
  • Stimmt etwas nicht?
#3,619 0 Kommentare 0 Reaktionen 0 zugewiesene Personen Auf GitHub ansehen

Maintainer antworten meist innerhalb von 3 Tagen

Dieses Issue hat noch niemand übernommen.

Bewertung

Schwierigkeit
2/5
Geschätzter Aufwand
1-3 Stunden
Anfängerfreundlichkeit
88/100
Issue-Typ
Bug
Klarheit
Klar beschrieben
Aktivitätsstatus
Aktiv
Tech-Stack
go
Bereich
infrastructure

Rechercherichtung

Beginne in packages/envd/internal/api/init.go:607 und untersuche, wie nfsOptions für Sandbox-Volume-Mounts verwendet wird. Vergleiche dies mit packages/orchestrator/pkg/nfsproxy/e2e_start.sh:29 und den Filestore-Mount-Konfigurationen und führe anschließend die flock-Reproduktion aus, um zu bestätigen, dass die Sperre des gemounteten Volumes umgehend zurückgegeben wird, statt zu hängen.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Beschreibung

Sandbox ID or Build ID

iu5wt6ki121fvvkv6cklc (stuck process), iqop9y9ik26oaud4l4tky (remount test)

Environment

e2b JS SDK 2.46.0, sandbox guest Ubuntu 24.04, host macOS 15.6.
Volumes mounted through volumeMounts on Sandbox.create.

Timestamp of the issue

2026-09-04 13:47 UTC

Frequency

Happens every time

Expected behavior

flock() on a file in a mounted volume either succeeds as a node-local lock, or fails promptly with an error such as ENOLCK.

Actual behavior

It blocks forever in uninterruptible sleep (state D). The process cannot be killed, not even with SIGKILL, and it holds the sandbox until the sandbox itself is destroyed.

Reads and writes on the volume are fine. Only locking hangs.

Kernel stack of the stuck process:

__do_sys_flock → nfs_flock → nfs3_proc_lock → nlmclnt_lock → nlmclnt_call → rpc_wait_bit_killable
Issue reproduction
  1. Create a volume and mount it on a sandbox:
const volume = await Volume.create('flock-repro')
const sbx = await Sandbox.create('<template>', {
  volumeMounts: { '/mnt/vol': volume },
})
  1. In the sandbox, take a lock on the volume and on local disk for comparison:
touch /mnt/vol/f /tmp/f
timeout 10 flock /mnt/vol/f -c true; echo $?   # 124, blocked
timeout 10 flock /tmp/f      -c true; echo $?  # 0
  1. The first command never returns. cat /proc/<pid>/stack shows the trace above, and cat /proc/<pid>/wchan reads rpc_wait_bit_killable.
Additional context

Cause. nfsOptions in packages/envd/internal/api/init.go:607 sets neither nolock
nor local_lock, so local_lock defaults to none and the kernel sends every lock to
the proxy as an NLM request. go-nfs has no lock manager, and the portmapper answers the
lookup for one with port 0 (pkg/portmap/main.go:59). Because the mount is hard, the
client retries the bind forever instead of failing.

Fix. Add "nolock" to nfsOptions. Locks then resolve locally, which is the correct
semantics anyway given the proxy has no lock manager.

Why this looks like an omission. The same server is mounted with nolock everywhere
else in this repo:

  • packages/orchestrator/pkg/nfsproxy/e2e_start.sh:29 mounts the nfsproxy with nolock,
    so the e2e suite never runs the configuration production uses.
  • The Filestore chunk cache mount sets "nolock", // do not use locking.
  • The host Filestore mount sets "lock", "local_lock=none" deliberately, where a real
    NLM-capable server is on the other end.

Only the sandbox volume mount leaves the choice unmade. Upstream has the same report
against go-nfs, closed by the reporter with "Using nolock solved this":
https://github.com/willscott/go-nfs/issues/98

Use case. We hit it with the Codex CLI, which takes an flock in $CODEX_HOME. The failure is silent: no error, no timeout, no log.

Vorherrschende Sprache
Go
Sterne
1.6k
Forks
448
Keine gemergten PRs in 30 T.

Entwicklungsumgebung

In Codespaces öffnen

Startet den Dev-Container des Projekts im Browser, mit Ihrem eigenen GitHub-Konto.

Erste Schritte

  1. Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
  2. Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
  3. Forken Sie das Repository und arbeiten Sie in einem Branch.
  4. Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.

Mehr aus e2b-dev/runtime

Alle Issues in e2b-dev/runtime

Ähnliche Issues

Weitere Issues zu Go

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.