Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

json-file logging does not recover after ENOSPC and can block container output

Aperta
#5,257 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 2 giorni

@alongubkin ci sta già lavorando.

Dal 6/10/2026.

  • #5249 di @alongubkin — aperta

Valutazione

Difficoltà
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
20/100
Tipo di issue
Bug
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
go
Ambito
backend

Direzione di ricerca

Start with the reproducer docs/testing/repro-json-log-enospc.sh and its explanation in docs/testing/json-log-enospc.md, then read the JSON log consumer and its json.Encoder write path. Done means logging resumes after a transient ENOSPC without blocking output, with regression tests for both async consumers, persistent failure, partial writes and synchronous recovery. Open PR #5249 already implements this, so coordinate with it before starting.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

Description

A transient JSON log write failure can permanently stop logging, even after disk space is available again. With nerdctl 2.2.2, the asynchronous JSON consumer exits on the first failed write; the producer channel and stdout/stderr FIFO then fill, blocking container output. On the PR base (add513266aea6883b60a3e54ba2ef4ced948c903), JSON logging uses synchronous writes, but its json.Encoder retains the first writer error and never resumes writing later entries.

This report uses only a synthetic Alpine container and a private 8 MiB tmpfs. No host filesystem is filled and no existing workload is modified.

Steps to reproduce the issue

On a disposable Linux host with root access, containerd, Bash and standard mount/dd/grep tools:

curl -fsSL https://raw.githubusercontent.com/alongubkin/nerdctl/afcad2e3/docs/testing/repro-json-log-enospc.sh -o repro-json-log-enospc.sh
sudo bash repro-json-log-enospc.sh /path/to/nerdctl

The script:

  1. Starts a fresh container in a unique namespace. Its JSON log is on a private 8 MiB tmpfs; its progress counter is on a different filesystem.
  2. Fills only that tmpfs and verifies the filler write fails with ENOSPC.
  3. Produces 30,000 lines on each output stream, exceeding the old per-stream producer channel capacity.
  4. Frees space and checks that the workload finishes and both recovery markers reach the JSON log.
  5. Removes its container and temporary mount/files. Pulled image content can remain cached.

Rotation is bounded (max-size=1m,max-file=2) to prevent immediate re-exhaustion after the filler is removed. The default snapshotter is overlayfs; use sudo env SNAPSHOTTER=native bash ... if native is configured. CONTAINERD_ADDRESS selects another daemon socket. The selected snapshotter must be supported by containerd's image unpack configuration.

Reproducer and explanation.

Describe the results you received and expected

Observed with the same synthetic workload:

Binary Result after freeing space
nerdctl 2.2.2 Container output stays blocked at approximately 10,000 iterations; script exits 1.
Unmodified PR base add51326 Workload completes, but neither recovery marker reaches the JSON log; script exits 1.
PR #5249 Workload completes all 30,000 writes per stream; both markers are logged; script exits 0.

Expected: continue consuming output while writes fail, dropping unwritable records, and resume logging subsequent records after the sink recovers. Lost records cannot be recovered. A partial record left by a failed write is a separate corruption concern; it must not be joined to the next valid record.

The PR also includes regression tests for both asynchronous consumers, persistent write failure, partial writes followed by recovery, and synchronous recovery. All three fail against the unchanged implementation and pass with the fix.

What version of nerdctl are you using?
  • Released nerdctl 2.2.2.
  • Unmodified PR base add513266aea6883b60a3e54ba2ef4ced948c903, built with make BUILDTAGS=no_ipfs.
  • Fixed implementation from PR #5249, with reproducer at afcad2e3.
Are you using a variant of nerdctl?

No. Official release binaries and builds from upstream source.

Host information

Disposable rootful Linux arm64 test environment; kernel 7.0.14-orbstack-00374-gbbca68e8d741; native snapshotter. The released 2.2.2 test used containerd 2.2.1; the source-base/fixed comparison used containerd 2.4.1 with native unpack configured. runc 1.4.0. Only the logging implementation differed between the source-base and fixed comparison.

Related fix: #5249. Prepared with Codex assistance; the failure, recovery, and regression tests were run locally.

Lingua principale
Go
Stelle
10.4k
Fork
834
Merge medio
2g 14h
PR unite (30g)
30

Preparare l'ambiente

  • Include un Dockerfile o un file Docker Compose
  • Nessun modello di pull request
  • Nessuna guida per i contributori

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di containerd/nerdctl

Tutte le issue di containerd/nerdctl

Issue simili

Altre issue su Go

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.