fix(djpeg): reap the child process when decoding fails

[PaulEdwardsAP]

Fixes #197.

The bug

Djpeg.run() only calls cmd.Wait() on the success path. When bmp.Decode(stdout) fails it returns immediately, so the child is never reaped:

img, err := bmp.Decode(stdout)

if err != nil {
    return nil, err          // <-- child never reaped
}

if err := cmd.Wait(); err != nil {   // only reached when decoding succeeded

So every file djpeg cannot decode leaks one zombie per attempt — and Get()'s two-pass resize calls run() twice, so up to two per file per index pass.

exec.CommandContext kills the process when the context is cancelled, but killing is not reaping; a Wait() is still required.

Why it bites harder than it looks

In a container the zombies accumulate until the cgroup pids limit is reached, after which every fork/exec inside the container fails. That includes ffmpeg, so video thumbnails silently stop being generated while photos keep working (cached or embedded-EXIF thumbnails). It therefore presents as "some videos have no thumbnail", which is a long way from a process leak.

Observed on a 167k-file library containing ~147 undecodable .jpg files: 1,547 zombie djpeg processes, pids.current pinned at the 1578 default, and pids.events recording 3,745 hits on the limit.

The change

cmd.Wait() is now called on every path.

Error precedence is deliberately unchanged — a decode error is still returned ahead of a non-zero exit status, so callers see exactly what they saw before. Only the reaping is new.

Test

TestRunReapsChildOnDecodeFailure counts this process's zombie children across 20 failed decodes of a non-JPEG file. On the previous code it fails with:

djpeg_test.go:84: leaked 20 zombie(s) over 20 failed decodes (before=0 after=20)

and passes with the fix. TestRunReapsChildOnSuccess covers the success path and encodes its own sample JPEG, so neither test needs fixtures. Both skip when djpeg is absent or off Linux (reaping is only observable via /proc).

Not affected

internal/io/ffmpeg/ffmpeg.go uses cmd.Output(), which waits internally — I checked, and it has no equivalent problem. (The issue speculated it might; it does not.)

[Copilot]

🟢 Approval recommended

The focused fix correctly addresses the process leak and includes suitable regression coverage.

0 open findings

What changed in this PR

Fixes zombie djpeg processes caused by decode failures, preventing eventual PID exhaustion.

Changes:

• Unconditionally waits for djpeg after decoding while preserving error precedence.
• Adds Linux regression tests for failure and success paths.

File	Description
internal/​io/​djpeg/​djpeg.go	Reaps the child process on every decode path.
internal/​io/​djpeg/​djpeg_test.go	Verifies child reaping through /proc.

🧠 Review effort: Balanced

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[SmilyOrg]

@PaulEdwardsAP thanks for your contribution!