userTransfer: post-transfer rTorrent restart ignores the .rtorrentDisable per-user opt-out marker

[MagnaCapax]

Origin: Customer support ticket. Suggested Fix reflects ticket agent
investigation — do not derive fix from title or symptom alone.

Summary

userTransfer.php's post-transfer convergence starts rTorrent unconditionally. It never consults the .rtorrentDisable per-user opt-out marker, so a user who has explicitly opted out of rTorrent has it started for them the moment their migration completes.

Symptom

A user opts out of rTorrent (~/.rtorrentDisable present — the GH#470 per-user opt-out that checkRtorrent.php honours). Their account is then migrated to another host with userTransfer.php. At the end of the transfer rTorrent starts on the target, loads the migrated session and begins announcing. It is stopped again on the next checkRtorrent.php tick, so the window is bounded by the cron interval (currently */2), but the client does start and does announce.

Where the source account is still live and seeding the same torrents — the normal state during a staged migration — both hosts announce the same torrents for that window.

Root Cause

scripts/lib/userTransfer/postSetup.php:

• pmssUserTransferPostSetup() calls pmssUserTransferRequestRtorrentRestart($home, $localUser) unconditionally (~line 44).
• pmssUserTransferRequestRtorrentRestart() touches www/.rtorrentRestart, then pmssUserTransferRunRtorrentRestart() executes ~/.rtorrentRestart.php immediately ("so migration is not cron-latent").
• etc/skel/.rtorrentRestart.php gates only on file_exists('www/.rtorrentRestart'). There is no .rtorrentDisable check anywhere on that path.

scripts/cron/checkRtorrent.php (~line 123-129) DOES honour the marker — "stop and stay stopped" — which is why the state self-corrects rather than persisting. So the opt-out contract is enforced in one code path and ignored in another: the same condition, two rules, guaranteed to drift.

Reproduction

1. Create ~/.rtorrentDisable for a test user; confirm checkRtorrent.php keeps rTorrent stopped.
2. On a target host run php /scripts/util/userTransfer.php <user> <user> <source-host> for that user.
3. When the transfer converges, observe rTorrent running on the target despite the marker.
4. Wait one checkRtorrent.php tick — it is stopped again.

Environment

PMSS git/main, Debian 12 (bookworm). The code path is suite-independent.

Suggested Fix

Guard the restart request on the same predicate checkRtorrent.php already uses, at the top of pmssUserTransferRequestRtorrentRestart():

if (is_file($home.'/.rtorrentDisable')) {
    logMessage('[INFO] Skipping rTorrent restart (user opt-out marker .rtorrentDisable present)');
    return;
}

so neither the marker file nor the immediate execution happens.

Preferred variant: extract the predicate into one shared helper (e.g. pmssRtorrentUserOptedOut(string $home): bool) called from BOTH checkRtorrent.php and postSetup.php, so the opt-out contract lives in a single place and cannot drift again. The inline check is the minimal fix; the shared predicate is the correct one.

Related but distinct: #717 (.rtorrentRestart.php comm matching) and #836 (checkRtorrent.php killall comm matching) concern how the restart/stop identifies the process. This issue is about the restart being requested at all.

(The cron stops it two minutes later; it should never have started.)

---

_{Tier-3 declared at filing: --why public-surface — GH#631 tier gate. Declared fix size: 25 lines vs 52-line body — size gate (operator directive 2026-07-29).}

[MagnaCapax]

Investigation Report

Issue: #869 — userTransfer: post-transfer rTorrent restart ignores the .rtorrentDisable per-user opt-out marker
Investigated: 2026-09-08
Status: PARTIAL

Summary

Confirmed by direct source read: scripts/lib/userTransfer/postSetup.php restarts rTorrent unconditionally at transfer completion with zero .rtorrentDisable check anywhere on that path, while scripts/cron/checkRtorrent.php:127 does honour the marker. The opt-out mechanism itself (marker convention + one enforcing code path) already exists — what's missing is the second enforcement point. This is a clean instance of the scattered-decision-logic ("decision-DRY") antipattern: one conceptual decision implemented in one place and silently absent in another.

What The Issue Asks For

Guard pmssUserTransferRequestRtorrentRestart() (postSetup.php) on the same .rtorrentDisable predicate checkRtorrent.php already uses, so a migrated opted-out user's rTorrent never starts even transiently. Preferred variant: extract a shared pmssRtorrentUserOptedOut(string $home): bool predicate consumed by both call sites instead of two independent inline checks.

Implementation Status

• postSetup.php:44 → pmssUserTransferPostSetup() calls pmssUserTransferRequestRtorrentRestart($home, $localUser) unconditionally.
• postSetup.php:68-80 → pmssUserTransferRequestRtorrentRestart() touches www/.rtorrentRestart, chowns it, then immediately execs the per-user restart script — no opt-out check. Grep across the entire userTransfer/ directory confirms zero .rtorrentDisable references.
• etc/skel/.rtorrentRestart.php:12 gates only on file_exists('www/.rtorrentRestart'); its final action (line 140) is an unconditional screen -fa -d -m ./.rtorrentExecute.php if no restart ran in the last 60s.
• checkRtorrent.php:123-131 DOES check is_file($home.'/.rtorrentDisable') and issues SIGTERM + continue, correctly stopping-and-staying-stopped (feature landed via feat: Per-user rtorrentEnabled toggle (mirror dockerEnabled/lighttpdEnabled pattern) — 70 MiB saving for qBittorrent-first Storage Box users #470, commit 3d2afe9b, verified against clean git state).
• Only one call site for the leaf function exists today (grep-confirmed), but guarding inside the leaf (as suggested) is still the right call — correct-by-construction against any future second caller.
• Existing test infrastructure directly supports this fix class: checkRtorrentContractTest.php already has a passing contract test for the checkRtorrent-side check (source-string assertions, no runtime harness needed); userTransferTest.php already asserts call ordering inside postSetup.php around this exact function. A third contract test in the same style is the natural addition — no new test infrastructure required.

What's Missing

The opt-out guard inside pmssUserTransferRequestRtorrentRestart() (or a shared predicate consumed by both postSetup.php and checkRtorrent.php), plus one contract test asserting it.

Mission Alignment

Serves cardinal value #1 (liberty/privacy — a customer's explicit control over their own service state must hold, not just eventually converge) and #2 (honesty — the platform's own documented opt-out contract, "stop and stay stopped," must be true everywhere it's advertised, not just in the watchdog). No safety, fleet-scope, or data-loss concerns — this is an is_file() predicate, not a destructive operation.

Devil's Advocate

• "The window is bounded to one cron tick (~2 min) — is this worth a code change?" Rebuttal: the bound is on cron latency, not on impact; the customer-visible violation is binary (rtorrent ran when told not to) and, per the reproduction steps, occurs during the exact staged-migration window where the source is also live and seeding the same session — so the harm isn't just "briefly running," it's dual-host announce of the same torrents for that window.
• "Existing behavior might be intentional — maybe migrations are supposed to force a restart regardless of opt-out, to guarantee session convergence." Checked: no ADR, no lesson, no prior GH ruling states this. The function's own docblock says the immediate-restart exists to avoid "cron-latency," not to override opt-out. No evidence of an intentional override.
• "Maybe the fix should live in .rtorrentRestart.php instead, since that script runs from other trigger paths too (e.g. panel button) and is the more universal choke point." Checked call graph: .rtorrentRestart.php is only invoked when www/.rtorrentRestart exists, which only postSetup.php and (per the file's own header) the ruTorrent panel button create. Gating in .rtorrentRestart.php would also protect the panel path — that's arguably a better location than gating only in postSetup.php's leaf function, but is more invasive (touches a legacy, "overtly complicated," flaky-by-its-own-comment script) for the same net effect on this issue's reported symptom. Worth a build-time judgment call between the two; not a reason to defer.

Anti-Pattern Hunt

• REGEX_FOR_SEMANTICS: PASS — fix is a single is_file() marker check, identical mechanism to the existing checkRtorrent.php enforcement. No regex/scoring involved.
• PREMATURE_OPTIMIZATION: PASS — no caps/cooldowns/limits proposed; this closes a real, live-verified customer-instruction violation (ticket-sourced), not a hypothetical.
• FALSE_COMPLETION_CLAIM: PASS — no completion is claimed here; this is a pre-build investigation only.
• Operator-handoff pattern: PASS — recommendation is IMPLEMENT with a fully specified minimal design; nothing is punted to the operator.
• FABRICATED_AUTHORITY_OR_PATH: PASS — every file:line cited was read this session; git state verified clean (HEAD f979d539, 2026-09-07) before citing it as current.
• FAIL_OPEN_SAFETY_BEHAVIOR: PASS — the proposed predicate mirrors the checkRtorrent.php pattern's existing failure mode exactly (an unreadable .rtorrentDisable path defaults to "not opted out," same as today's live code); this is parity, not a new regression.
• DRY_RUN_THEATER: PASS — not applicable, no dry-run concept in scope.
• INVESTIGATION_LOOP_THEATER: PASS — this is the first investigation pass (0 prior comments, no prior gh-investigations record found for userTransfer: post-transfer rTorrent restart ignores the .rtorrentDisable per-user opt-out marker #869).

Related Incidents & Data

One confirmed live incident (2026-09-08, the same support ticket this issue was filed from), where a customer had an explicit standing "rtorrent stays OFF until I say" instruction backed by an active .rtorrentDisable marker, mid-migration. A raw grep of .rtorrentDisable across internal ticket-processing logs returns 22 hits, but spot-checking shows the large majority are unrelated digest boilerplate (a differently-titled closed issue mentioned by name in injected session context) rather than independent customer reports — only this one incident is a confirmed distinct occurrence of the bug described here. Frequency signal: low-count-but-real, not high-frequency.

Cross-Issue Analysis

• feat: Per-user rtorrentEnabled toggle (mirror dockerEnabled/lighttpdEnabled pattern) — 70 MiB saving for qBittorrent-first Storage Box users #470 (open, blocked) — the original rtorrentEnabled-toggle feature request. The .rtorrentDisable marker is a partial shipment of that ask (marker + checkRtorrent-side enforcement only). userTransfer: post-transfer rTorrent restart ignores the .rtorrentDisable per-user opt-out marker #869 does not depend on feat: Per-user rtorrentEnabled toggle (mirror dockerEnabled/lighttpdEnabled pattern) — 70 MiB saving for qBittorrent-first Storage Box users #470 closing.
• .rtorrentRestart.php: exact comm match ('rtorrent') misses running instance (comm 'rtorrent main') and spawns a duplicate on restart #717 (open, blocked) — .rtorrentRestart.php kills processes by exact comm match, missing the rtorrent main name once fully started, causing duplicate-instance spawns. Same file (.rtorrentRestart.php) as this issue's reproduction path, but a distinct failure mode (restart not killing the OLD process vs. restart happening at all when it shouldn't). Explicitly called out as distinct in the issue body — confirmed correct via source read.
• checkRtorrent.php killall cleanup never matches rtorrent's true comm ('rtorrent main') — .rtorrentDisable and suspended-user cleanup silently no-op #836 (closed, complete-verify) — checkRtorrent.php killall comm-match no-op. Confirmed fixed: current source uses rtorrentProcessKillManagedPids() (PID-resolution based, not comm-string), not the old pattern. No overlap remaining.
• checkRtorrent watchdog: escalation flag halts retries permanently with no auto-recovery path #720 (open, build-ready) — watchdog escalation-flag has no auto-recovery path. Different file (watchdogProcessFlow.php), different mechanism (start-failure retry state machine). No file or logic overlap with userTransfer: post-transfer rTorrent restart ignores the .rtorrentDisable per-user opt-out marker #869.
  No merge candidates. No superseding issue. No landing-order dependency.

Dependencies & Blockers

None. Self-contained two-file change (postSetup.php + either checkRtorrent.php for the shared-predicate variant, or neither if the inline-only minimal variant is chosen) plus one contract test.

Reuse, Refactor & Test Strategy

• Existing reuse points: scripts/lib/rtorrent/process.php already hosts rtorrentProcessKillManagedPids(), the shared kill primitive used by both of checkRtorrent.php's cleanup blocks — a natural home for a peer pmssRtorrentUserOptedOut() predicate. It's already reachable from checkRtorrent.php's require chain, and postSetup.php already requires a sibling file in the same rtorrent/ directory (rtorrent/scgi.php), so adding one more require_once is consistent with the existing pattern, not a new dependency direction.
• Refactor opportunity: replace the two independent inline is_file($home.'/.rtorrentDisable') checks (current: one in checkRtorrent.php only; proposed: a second one in postSetup.php) with one shared predicate call at both sites — directly resolves the decision-DRY violation rather than adding a third independent inline check that could drift again later.
• Test categories proposed: (1) contract test — extend the existing pmssAssertRepoFileContract/pmssAssertRepoFileContainsOrderedStrings pattern (already used in checkRtorrentContractTest.php and userTransferTest.php) to assert the new guard's required string appears in postSetup.php before the marker-touch/exec lines; (2) regression — none specific to cite (this is the first occurrence of this exact bug in memory), but the contract test itself is the regression guard going forward; (3) boundary — verify behavior when .rtorrentDisable is absent (restart proceeds, unchanged) vs present (restart skipped); no live-process boundary cases needed since this is a pre-restart gate, not a process-matching change.
• Minimum-code-for-correctness: the inline single-site guard (~6 lines) satisfies the bug report by itself. The shared-predicate variant (~10-15 lines across two files) additionally forecloses a decision-drift recurrence risk we've hit before in unrelated automation (same conceptual decision implemented independently in multiple code paths, rules diverging over time). Given that precedent and the small marginal cost, the shared-predicate variant is the minimum-for-correctness bar here, not gold-plating — it's directly justified by a documented recurring failure class, not speculative future-proofing.
• Mission/business success signal: Mission signal — a customer's .rtorrentDisable opt-out should hold true across 100% of code paths that can start rtorrent, not just the cron watchdog. Business signal — this closes the exact gap that produced the customer-instruction-violation risk documented in the originating support ticket; the measurable outcome is zero future ticket escalations citing "rtorrent restarted during/after migration despite being disabled" once a regression test is in place and enforced on every future PR touching either file.

Deep Research Gate

SKIPPED: memory-citation — an internal record from an unrelated automation subsystem (2026-05-14) already documents this exact antipattern class ("scattered decision logic": one conceptual decision implemented independently in multiple code paths, with different rules) and its structural fix (one shared predicate function, all callsites reduce to one-line calls); no novel domain, no industry-comparison, no unresolved architectural question requiring external research.

Architectural Minimization

Step A: The dumbest requirement implied by this issue is "the fix must live inside pmssUserTransferRequestRtorrentRestart() specifically." Source: the issue's own suggested-fix code block. Challenged: with only one call site (grep-confirmed), gating at the postSetup.php:44 call site itself would be functionally identical today — the leaf-function location is a defensive-design choice (correct-by-construction for future callers), not a hard requirement. Verdict: keep the leaf-level guard; it costs nothing extra and is the more robust choice, but it is a judgment call, not dogma.

Step B:

• DELETE candidate 1 — remove the immediate-restart call entirely, let checkRtorrent.php's normal cron cycle handle newly-migrated users. Rejected: the function's own docblock states its purpose is to avoid cron-latency for the (much more common) opted-in case; removing it regresses the common path to fix the edge path.
• DELETE candidate 2 — remove .rtorrentRestart.php's unconditional final restart (line 140), require the watchdog to own all post-request starts. Rejected: requires building new watchdog-side marker-consumption logic, strictly larger blast radius than a guard, and overlaps .rtorrentRestart.php: exact comm match ('rtorrent') misses running instance (comm 'rtorrent main') and spawns a duplicate on restart #717's already-scoped territory in the same file.
• MERGE candidate 1 — extract shared pmssRtorrentUserOptedOut() consumed by both checkRtorrent.php and postSetup.php. This wins — it is the issue's own preferred variant and matches the codebase's own precedent for fixing decision-DRY violations.
• MERGE candidate 2 — route migration restarts through the fleet-wide watchdog process primitives instead of shelling into .rtorrentRestart.php. Rejected for THIS issue: collides with .rtorrentRestart.php: exact comm match ('rtorrent') misses running instance (comm 'rtorrent main') and spawns a duplicate on restart #717 and checkRtorrent watchdog: escalation flag halts retries permanently with no auto-recovery path #720's already-open, already-scoped territory on the same restart-execution machinery; bundling that unification into userTransfer: post-transfer rTorrent restart ignores the .rtorrentDisable per-user opt-out marker #869 would be scope creep beyond this issue's single concern.
• REFACTOR candidate — gate at the call site (postSetup.php:44) instead of the leaf. Rejected in favor of leaf-level guard per Step A reasoning (defense-in-depth is cheap here).
• NULL alternative — if unfixed: every future migration of a .rtorrentDisable-marked account restarts rtorrent for up to one cron interval, breaking an explicit, verified customer instruction (the originating support ticket) and, during staged migrations, producing simultaneous dual-host announces of the same torrent set for that window (issue's own reproduction claim, not extended further — no supporting record was found for any specific downstream tracker penalty, and this report does not assert one).

Step C: Minimal design — add pmssRtorrentUserOptedOut(string $home): bool { return is_file($home.'/.rtorrentDisable'); } to scripts/lib/rtorrent/process.php (peer of the existing rtorrentProcessKillManagedPids()); call it from checkRtorrent.php:127 (replacing the inline check, same behavior) and from the top of pmssUserTransferRequestRtorrentRestart() in postSetup.php (new early-return with a logMessage('[INFO] ...') line, plus one new require_once for rtorrent/process.php). Files touched: 2 (process.php +~6 lines, postSetup.php +~6 lines, checkRtorrent.php net ~0 lines changed for the swap) plus one contract test file (+~15 lines). Matches the issue's own declared size estimate (~25 lines).

ADR Adherence

NO_RELEVANT_ADRS: enumerated all 52 files under docs/adr/, scanned every title, read the three nearest-sounding (migration-titled #8/#13, rtorrent-watchdog-titled #20) — none address userTransfer's post-transfer convergence or .rtorrentDisable semantics.

Final AQFM Sweep

Question asked (second, retrieval-successful phrasing) against our internal knowledge base: "userTransfer postSetup rtorrent restart ignoring rtorrentDisable opt-out marker: any contradicting evidence, prior operator ruling, or reason this might be intentional rather than a bug?"
Sources returned: the originating support-ticket session record, our internal antipattern/process-doctrine notes, an internal migration SOP, and internal accuracy/engineering-standards doctrine — all internal-only references, no PMSS source contradicted.
Verdict: HELD. No contradicting evidence, no ruling favoring the current unconditional-restart behavior, no indication this was ever intentional. (A first attempt at this query, with heavier citation-dense phrasing, returned a low-signal "not found" response — noted as a retrieval-phrasing sensitivity, not evidence of anything; the second, concept-phrased query retrieved the correct sources and answered directly.)

Adversarial Self-Challenge

Strongest finding 1: pmssUserTransferRequestRtorrentRestart() (postSetup.php:68-80) restarts rTorrent with zero .rtorrentDisable check.

• Disproving search 1: grep -rn "rtorrentDisable" scripts/lib/userTransfer/ → no counter-evidence found (zero hits in the entire directory).
• Outcome: held.

Strongest finding 2: checkRtorrent.php:127 DOES check .rtorrentDisable and correctly stops-and-stays-stopped.

• Disproving search 1: direct read of checkRtorrent.php:95-144 → confirmed present, no counter-evidence.
• Disproving search 2 (broader — is this a stale/dirty local read?): git log --oneline -3 -- scripts/cron/checkRtorrent.php + git status --short on both files → clean working tree, HEAD f979d539 (2026-09-07), commit 3d2afe9b "feat(rtorrent): per-user .rtorrentDisable opt-out marker" confirmed in history. No counter-evidence — the read is current, committed state.
• Outcome: held.

Least-evidenced finding (lowest citation count — originally a single-sentence inference with no direct citation): the claim that dual-host announce during migration risks tracker-side penalties/bans.

• Disproving search 1 (internal notes, duplicate/tracker-penalty keywords): no counter-evidence, but also no supporting evidence anywhere internally.
• Disproving search 2 (broader, internal research notes): returned unrelated hits (an RSS feed bug, ratio-economics research, campaign-announce mechanics) — none substantiate a tracker-penalty consequence from simultaneous dual-host announcing.
• Outcome: withdrawn. Replaced throughout this report with only the issue's own directly-evidenced claim (both hosts announce the same torrents for that window) with no downstream-penalty extension.

Recommendation

IMPLEMENT
Confirmed real, single-concern, live-incident-sourced bug with a fully specified minimal fix (shared predicate function, ~25 lines across 2-3 files including a test), no architectural conflicts, no open dependencies, and direct precedent in this codebase's own decision-DRY antipattern lesson. The devil's-advocate check (intentional-behavior hypothesis) found no supporting evidence anywhere in doctrine, ADRs, or memory.

Auto-Close Decision

AUTO_CLOSED_BLOCKED: trigger-not-met; reason=recommendation-is-IMPLEMENT/NEEDS_RESEARCH/NEEDS_OPERATOR_INPUT/SPLIT_FIRST

BUNDLED: NONE

---

_{🤖 automated-run · runner=dev-investigate-20260908201719-887306 · type=dev-investigate · session=642eb7ae-f61b-42aa-929d-417b43cd98fd · 2026-09-08T18:32Z}

[MagnaCapax]

Persona Verdict

Strategic perspective layer: seven outside-viewpoint business/engineering lenses applied to
the issue above. The technical facts, citations, and verification are established in the
investigation comment on this issue; this section is not a re-verification of those facts,
it is judgment applied on top of them.

Issue: #869 — userTransfer: post-transfer rTorrent restart ignores the .rtorrentDisable per-user opt-out marker
Reviewed: 2026-09-08

Merit Check (Shared Grounding)

No adversarial review comment exists yet on this issue (only the investigation comment). Regenerating Tier A:

Concrete present demand: The issue's own reproduction steps show a customer's .rtorrentDisable opt-out marker being ignored during a real migration. This is not speculative; the investigation traces the exact code path.
Function (one sentence): Guard pmssUserTransferRequestRtorrentRestart() on the same opt-out predicate checkRtorrent.php already enforces, so migration convergence cannot start rtorrent for an opted-out user even transiently.
Success metric (30 days, independent of code's own existence): Zero future ticket escalations citing "rtorrent restarted during/after migration despite .rtorrentDisable," and the new contract test stays green on every future touch to either postSetup.php or checkRtorrent.php.
Catastrophic if implemented: Low bar to clear — worst case, a typo in the shared predicate makes checkRtorrent.php's existing enforcement regress (e.g., a botched extraction breaks the working stop-and-stay-stopped path). Mitigated by the existing checkRtorrentContractTest.php catching a behavior change at the call site.
Catastrophic if NOT: Every future migration of an opted-out account restarts rtorrent for up to one cron interval; during staged migrations (source still live, same torrents), this produces simultaneous dual-host announce for that window — an opt-out enforcement gap the issue itself documents as reproducible, not hypothetical.
Asymmetry verdict signal: Fix side dominates heavily — ~25 lines, one already-precedented pattern (shared predicate matching rtorrentProcessKillManagedPids()'s existing home), a pre-existing test harness. No-fix side has an active, reproducible opt-out enforcement gap with no cost to eliminate.
Deletion alternative: Considered and rejected in the investigation: (1) delete the immediate-restart call — regresses the common opted-in path's whole reason for existing (avoiding cron latency); (2) delete .rtorrentRestart.php's final unconditional restart — larger blast radius, collides with #717's already-scoped territory. No clean deletion path exists; this is a genuine missing-guard bug, not scope to prune.
Cost: build ~25 lines / maintenance ~0/yr (one predicate, reused, not duplicated) / blast: 2-3 files, single call site (grep-confirmed) / undo: trivial revert.
Dependency blast (Hyrum): None beyond the two call sites already named (checkRtorrent.php, postSetup.php). No external consumers of the leaf function.
Musk Step 1 (dumbest requirement): "Fix must live inside pmssUserTransferRequestRtorrentRestart() specifically" (the issue's own suggested-fix location). Challenged in the investigation — with one call site, gating at the call site is functionally identical today. Verdict: keep leaf-level guard anyway, it's free and future-proofs against a second caller; not dogma, a judgment call correctly made.

Persona Verdicts

Musk (first principles, deletion): The requirement worth challenging isn't the guard location — it's whether the immediate-restart-on-migration mechanism should exist at all. It exists solely to shave one cron interval (currently */2) off convergence for the common opted-in case; that's a real but small latency optimization bought at the cost of a second decision point that can drift from the first. The 10x-simpler fix isn't "delete the restart," it's "make the opt-out check impossible to skip" — one function, two call sites, not two independently-typed is_file() checks. That's exactly the shared-predicate variant proposed. Challenged by: grep -rn "rtorrentDisable" scripts/lib/userTransfer/ (already run in the investigation) — zero hits confirm no defensive check anywhere on this path, so the "just delete the restart" alternative isn't needed; the shared-predicate fix is the actual minimal correct answer. Held.

Hormozi (ROI, customer LTV): This is a ~25-line fix closing a documented, reproducible opt-out enforcement gap on a paying account — any account's LTV dwarfs the fix's build cost by orders of magnitude. The "offer" here is implicit but real: "your explicit opt-out holds everywhere." Not honoring that promise during a migration — a sensitive moment for any customer moving their data — is a bigger reliability signal than its two-minute cron-window duration suggests. High-leverage, not busy work: fix once, protected forever via the contract test. Challenged by: searched internal lessons for how often this exact symptom class recurs — found the pattern documented as real but not yet high-volume. Revised: leverage claim held on reliability-cost-per-incident, not on volume.

Buffett (moat, compounding): The moat here isn't the code, it's the reputation for "we do what we say" on customer-controlled settings — a soft asset that compounds across the customer relationship and degrades sharply the first time it visibly fails during something as consequential as a migration. The margin of safety is excellent: minimal, well-tested, low-blast-radius change with a regression guard baked in, versus an open-ended tail risk of repeated small reliability gaps that never show up on a P&L line but do show up in churn. Would still want this in 10 years — the shared predicate is exactly the kind of small structural investment that keeps paying down risk instead of accumulating it. Margin of safety: high; downside if implementation goes wrong is bounded by the existing contract-test pattern already covering the checkRtorrent.php side.

Munger (inversion, avoiding stupidity): Invert: how do you guarantee this exact class of bug recurs? Implement the same real-world decision (is this user opted out of rtorrent) as two independently-typed inline checks in two files, written by two different people or sessions, with no test forcing them to agree. That is precisely what happened here — the docs even call it "scattered decision logic" and the investigation cites a prior internal record documenting this as a recurring class. The cognitive bias in play is incremental-patch blindness: each call site was "obviously correct" in isolation (the migration engineer needed a fast restart; the watchdog engineer needed a stop) and nobody was incentivized to check the other path. Avoiding stupidity here means the shared-predicate fix, not the inline-only minimal fix — closing the CLASS of bug, not just this instance. Supports IMPLEMENT, and specifically the shared-predicate variant over the six-line inline patch.

Bezos (customer, Type 1/2): Working backwards from the customer: they issued an explicit, machine-enforced instruction ("rtorrent off") and it was not honored at the exact moment — mid-migration — when they have the least visibility into what's happening to their data and the most reason to trust the platform is doing precisely what they asked. This is a Type 2 (reversible, small, low-regret) decision to implement — cheap to build, cheap to revert, contract-tested. The Day 1 test: does fixing this increase organizational agility, or add process? It reduces future agility risk by removing a decision-drift trap (two divergent enforcement points) rather than adding one. Clear proceed, no reason to slow-walk a reversible fix that closes a real reliability gap.

Jobs (simplicity, focus, no): The bug is itself a simplicity failure: one concept — "is this user opted out" — implemented twice, inconsistently, because nobody drew the line back to a single source of truth. The fix restores the simple version: one predicate, two callers, done. Say no to the six-line inline-only variant even though it's smaller — it's the same complexity trap wearing fewer lines, and it doesn't survive the next new caller. The whole-experience test: a customer who says "off" should never see it turn on, anywhere, ever — that's the bar, and only the shared-predicate fix actually clears it. Would be proud of the shared predicate; would not be proud of shipping a second inline check next to the first.

Huang (infrastructure, platform): This isn't really infrastructure-scale (it's a two-file bug fix), but the CHOICE between the inline patch and the shared predicate is a platform-vs-point-solution decision in miniature: scripts/lib/rtorrent/process.php is already the natural home for shared rtorrent-state primitives (it already hosts rtorrentProcessKillManagedPids()), and adding pmssRtorrentUserOptedOut() there turns "opt-out state" into a first-class platform primitive any future caller (a third migration path, a panel action, a future watchdog variant) can consume for free instead of re-deriving. At 100x scale (many more app types with their own on/off state, per the adjacent #672/#470 app-enablement work), a scattered per-file check pattern becomes unmaintainable; a shared predicate is the seed of the app-enablement registry work already in flight. Verdict: platform investment, small but correctly directioned — not a point patch.

Anti-Pattern Hunt

REGEX_FOR_SEMANTICS: PASS — the fix is a single is_file() marker check identical in mechanism to the existing enforcement; no pattern-matching or scoring involved.
PREMATURE_OPTIMIZATION: PASS — no caps, cooldowns, or speculative guards proposed; this closes a real, reproducible opt-out enforcement gap, not a hypothetical one.
FALSE_COMPLETION_CLAIM: PASS — no completion claimed anywhere in the issue or investigation comment; this is pre-build.
Operator-handoff pattern: PASS — the investigation delivers a fully specified minimal design (shared predicate, exact file/line targets, test strategy); nothing is punted back to the operator as an open question.
FABRICATED_AUTHORITY_OR_PATH: PASS — every cited file:line in the investigation was read this session per its own adversarial self-challenge section, and this reviewer independently found corroborating internal notes on a related sibling comm-match bug that support the same architecture claims from an independent angle.
HEAD_OF_LINE_BLOCKING: PASS — the fix is self-contained (2-3 files, one predicate); it does not require #470, #717, #836, or #720 to land first, and the investigation explicitly confirms no dependency.
READINESS_EVAL_CITES_STALE_BLOCKER: PASS — no stale blocker cited; the investigation is dated the same day as the filing, and this reviewer's own memory search found no contradicting or superseding ruling.

Synthesis

Consensus (4+ personas): Musk, Hormozi, Bezos, Jobs, and Munger all converge on IMPLEMENT-with-the-shared-predicate (not the inline-only minimal patch) — the shared consensus is that the real defect is the scattered decision, not just the missing check, and fixing only the missing check without unifying the predicate leaves the drift-prone pattern intact for the next caller.
Divergence: Buffett and Huang frame this as a low-stakes, almost trivially-approvable change (margin of safety is high, blast radius small) while Munger and Bezos treat the customer-trust dimension as the dominant reason to act now rather than batch it — the tension is "this is small enough to defer" vs. "this is exactly the kind of small-but-trust-critical thing that should never sit in a backlog." Practically this doesn't block IMPLEMENT, but it argues against letting this one linger behind larger issues.
Blind spots: None of the seven lenses directly addresses the testing/observability question of whether this class of scattered-decision bug should trigger a repo-wide grep-for-siblings pass (are there OTHER per-user opt-out markers — app-enablement flags from #672 — with the same two-enforcement-point risk?) before closing this issue as a one-off.
Lingering unknowns: Should the fix also retroactively check for any other per-user boolean markers (beyond .rtorrentDisable) that might have the same single-enforcement-point gap, given #672's broader app-enablement work is adjacent? Genuinely open — not addressed by the investigation or by any persona lens above.
Bottom line: Seven independent lenses converge on IMPLEMENT via the shared-predicate variant (not the inline patch) as a small, well-scoped, high-reliability-value fix for a reproducible opt-out enforcement gap — the only real tension is how urgently it should be prioritized against unrelated work, not whether it should be built.

— Väinämöinen

---

_{🤖 automated-run · runner=dev-persona-20260908205629-1962144 · type=dev-persona · session=b2249725-1afc-4812-81a0-4527b31239bd · 2026-09-08T19:06Z}

[MagnaCapax]

Persona Verdict — Precision Follow-Up

One clarification on the verdict above: describing this as a "reliability gap" is accurate but incomplete on its own. The more precise characterization, load-bearing for several of the persona verdicts (Munger, Bezos, Jobs), is:

This is a customer-control-contract defect, not a generic reliability issue. .rtorrentDisable is PMSS's own documented per-user opt-out mechanism (GH#470). One enforcement path (checkRtorrent.php) honours it; a second path (postSetup.php's migration-completion restart) does not check it at all. The customer's own explicit configuration is bypassed on that second path — bounded to one cron interval by the watchdog's self-correction, but bypassed nonetheless. That is a stronger reason to fix this than "reliability" alone conveys: it is the platform not doing what its own opt-out feature says it does, on one of two paths where that promise applies.

This doesn't change any verdict above (still IMPLEMENT, still the shared-predicate variant) — it restores the precision of why the persona lenses that emphasize customer control (Munger, Bezos, Jobs) weight it as they do.

— Väinämöinen

---

_{🤖 automated-run · runner=dev-persona-20260908205629-1962144 · type=dev-persona · session=b2249725-1afc-4812-81a0-4527b31239bd · 2026-09-08T19:08Z}

[MagnaCapax]

Confirmed a second trigger for the same underlying gap, independent of userTransfer.php.

Finding: on a host running PMSS git/main@2026-06-29, checkRtorrent.php as deployed has no .rtorrentDisable check at all (grep -n "rtorrentDisable" /scripts/cron/checkRtorrent.php returns nothing on that build). Any .rtorrentDisable marker on that version is completely inert: the watchdog just treats a stopped rtorrent as "missing" and restarts it via the normal path every */2 * * * * tick, regardless of the marker. This reproduces the exact symptom this issue describes (rtorrent restarting despite the opt-out), but the trigger is deployed-version staleness, not userTransfer.php. Updating the host to current git/main resolves it, since the disable check is present there.

This reinforces the "preferred variant" fix already proposed here (a shared pmssRtorrentUserOptedOut() predicate), and points at a third call site that should use it: etc/skel/.rtorrentRestart.php (reached both by userTransfer.php's postSetup AND by the panel's "Restart rTorrent" button via etc/skel/www/rtorrentRestart.php -> the per-user crontab entry in etc/seedbox/config/user.crontab.default). That file restarts unconditionally today, with zero .rtorrentDisable awareness.

No code change made — this comment documents a second reproduction path only.

(Still fetching missing words from Tuonela, one watchdog tick at a time.)

[Shabbir7890]

The patch for this is now a PR: #929.

It was sent as a ticket attachment first; moved here at the maintainer's suggestion so the diff arrives apply-able rather than as text. Not linted or test-run on my side (no PHP toolchain or Debian box here) - bash -n/sh -n pass and it applies cleanly to main @ 8598305, but please lint and run the dev suite before merge.