fix(deploy): roll transmission back to 4.0.6 + µTP-off + wedge watchdog (0-B/s degradation) - #41
Merged
Conversation
…og (0-B/s degradation) transmission-daemon 4.1.3 degrades into a GLOBAL 0-B/s state after a short uptime: it stays connected to peers (Availability 100%) but transfers nothing on ALL torrents until restarted, silently breaking every RED/OPS download. First seen 2026-08-07 at 16-day uptime; recurred 2026-08-21 at only ~1.5 days (diagnosed live: torrent stuck "Downloading" 77%, 36 peers, 0 B/s; the whole daemon had moved 51 MB in 42h). A karaoke job (Regina Spektor – Blue Lips) failed on it; the exact same torrent+file downloaded in ~110s once the daemon was restarted, confirming the wedge (not rare-torrent unavailability). Root cause is the 4.1.0 transport rewrite (preferred-transport / µTP) and its regression stack (#8748, #8658, #8999). 4.1.3 is the newest release (no 4.1.4). Changes: - Pin transmission 4.0.6 (newest 4.0.x stable, predates the transport rewrite; explicitly RED-whitelisted). Add libdeflate/natpmp/miniupnpc build deps (4.0.6 doesn't vendor them) and apply upstream's miniupnpc-2.2.8 compat patch (febfe49ca / #6907) so it builds on Debian 13. Remove any stale /usr/local/bin binaries that would shadow /usr/bin in PATH. - settings.json mitigations (version-independent defence-in-depth): utp-enabled off (highest-value lever for the read-loop wedge; RED/OPS seed over TCP), dht/pex/lpd off (private torrents ignore them), peer-limit-per-torrent 50→30, cache-size-mb 16. Raise LimitNOFILE 1024→131072 via systemd drop-in. - Rewrite the maintenance restart as an hourly WEDGE WATCHDOG. The old daily guard had two fatal flaws: a 5-day threshold (degradation hit at ~1.5d) and "skip if any torrent is Downloading" — but a wedged download sits in "Downloading" forever, so it deferred the very restart that cures it. Now it restarts when torrents want data yet the aggregate rate is ~0 (sampled twice to never interrupt a live transfer), plus a preventive idle recycle past 48h. Validated live on the box: 4.0.6 running, 272 torrents intact, RED announce succeeds (no whitelist rejection), downloads transfer at 1.55 MB/s with µTP off, fd limit 131072, watchdog correctly no-ops on a healthy daemon. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Codecov Report✅ All modified and coverable lines are covered by tests.
Flags with carried forward coverage won't be shown. Click here to find out more. 🚀 New features to boost your workflow:
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
transmission-daemon4.1.3 degrades into a global 0-B/s state after a short uptime: it stays connected to peers (Availability 100%) but transfers nothing on all torrents until restarted, silently breaking every RED/OPS download. First seen 2026-08-07 at a 16-day uptime; recurred 2026-08-21 at only ~1.5 days.A karaoke job (Regina Spektor – Blue Lips, gen
44622ffa) failed withTorrent download stalled for 600s ... at 77.14%. Diagnosed live on the box: the torrent sat "Downloading" at 77%, 36 peers, 0 B/s; the whole daemon had moved 51 MB in 42h. The exact same torrent + file downloaded in ~110s once the daemon was restarted — proving the wedge (not rare-torrent unavailability; the "77.14%" was just the album-wide wanted-set completion fromkeep_seeding).Root cause: the 4.1.0 transport rewrite (preferred-transport / µTP) + its regression stack (upstream #8748, #8658, #8999). 4.1.3 is the newest release (no 4.1.4 → no forward fix); #8308 was fixed by downgrading to 4.0.5 — direct precedent.
Changes (all in
deploy/provision.sh)libdeflate/natpmp/miniupnpc-dev(4.0.6 doesn't vendor them) and apply upstream's miniupnpc-2.2.8 compat patch (febfe49ca/ #6907) soport-forwarding-upnp.cccompiles. Fail hard on a real patch failure; tolerate already-applied. Remove stale/usr/local/bincopies that shadow/usr/binin PATH.utp-enabled=false(highest-value lever for the read-loop wedge; seeds speak TCP),dht/pex/lpd=false(private torrents ignore them),peer-limit-per-torrent 50→30,cache-size-mb 16. RaiseLimitNOFILE1024→131072 via a systemd drop-in.Validation (applied + verified live on the box)
in_review).Notes
Reviewed locally with CodeRabbit (findings addressed: patch hunk header + fail-hard, watchdog cooldown).
@coderabbitai ignore