`direct_unpack` (`unrar -vp`) hangs forever on multi-volume RAR with unrar 7.2.3 — jobs wedge in PostProcessing

[brookesy2]

Summary

With direct_unpack = true (the default), multi-volume RAR jobs download to 100% and then hang indefinitely in PostProcessing. The unrar child process is spawned with -vp (pause between volumes) and never gets its continue keystroke, because the prompt-detection matches an obsolete prompt string that modern unrar (7.2.3 / 7.23) does not emit. The process blocks forever waiting on stdin.

This became a default-on, everyone-hits-it problem as of v1.3.6, which bundles unrar 7.2.3 into the Docker image (fixing #12). Before that, RAR extraction failed fast on the RAR-less Alpine 7z, so this path was never exercised in Docker.

Impact

• Every multi-volume RAR download (.partNN.rar) stalls in PostProcessing forever (single-part RAR is unaffected — no volume boundary).
• Stuck jobs pin unrar processes and never complete or fail, so Sonarr/Radarr never import and never fail over.
• Observed 4 jobs wedged 11–35 hours before diagnosis.

Environment

• rustnzb v1.3.5 observed; crates/nzb-web/src/direct_unpack.rs is unchanged in the current tree, so v1.3.6 is affected too.
• Docker image, base lscr.io/linuxserver/baseimage-alpine:3.23, bundled unrar 7.2.3 (per v1.3.6).
• direct_unpack defaults to true (crates/nzb-core/src/config.rs).

Evidence

Hung processes (all multi-volume sets, all -vp, sleeping on stdin for hours):

unrar x -o+ -y -vp -p-  .../incomplete/<job>/<set>.part1.rar  .../complete/tv/<name>/

Job status snapshots show status=PostProcessing pct=100.0 kbps=0 with idle_secs climbing into the tens of thousands and never resolving.

Root cause in crates/nzb-web/src/direct_unpack.rs — the continue path only fires when the output contains "[C]ontinue, [Q]uit":

// Spawn unrar with -vp (pause between volumes).
.args(["x", "-o+", "-y", "-vp"])
...
// Check for volume prompt. unrar -vp outputs a line like:
//   "Insert disk with <filename> [C]ontinue, [Q]uit "
if line_trimmed.contains("[C]ontinue, [Q]uit")
    || line_trimmed.contains("[C]ontinue, [Q]uit")   // <- duplicated condition (typo)
{
    ... wait_for_volume(...) ... sin.write_all(b"C\n") ...
}

unrar 7.2.3 does not print "[C]ontinue, [Q]uit" at a volume boundary, so this branch never runs, "C\n" is never sent, and the process blocks on the pause prompt indefinitely. (The duplicated || condition checks the same string twice — harmless, but indicates the branch was never exercised against a real unrar.)

Reproduce

1. Docker v1.3.6 (or v1.3.5 with a real unrar 7.2.x on PATH), direct_unpack = true.
2. Grab any multi-volume .partNN.rar release.
3. Download reaches 100%, then the job sits in PostProcessing forever; ps shows a stuck unrar … -vp ….

Workaround

Set direct_unpack = false — the post-download path (nzb-postproc) uses unrar x -o+ -y -p- -ai -idp (no -vp) and extracts multi-volume sets cleanly.

Suggested fix

• Update the volume-prompt detection to match unrar 7.x output, or drop -vp entirely and let unrar walk the volume set itself (all parts are present by the time extraction runs), or run the non-interactive nzb-postproc args on the direct path too.
• If keeping the streaming/-vp design, add a watchdog/timeout so a job can never sit idle in PostProcessing indefinitely, and fix the duplicated condition.
• Consider defaulting direct_unpack = false until the prompt handling is verified against the bundled unrar in CI (the release smoke test added in v1.3.6 covers unrar t but not the -vp direct-unpack path).

Related

• Docker image ships without unrar → all RAR downloads fail post-processing ("Cannot open the file as archive") #12 — bundling unrar in the Docker image; that fix activated this latent bug by default.