fix(linux): avoid blocking proc reads for WSL agents - #2179
Conversation
📝 WalkthroughWalkthroughLinux process metadata now includes process state. Foreground-group discovery and process-agent lookup guard command-line reads for unsafe states and known WSL agents. WSL detection is cached, and tests cover state parsing and wrapper handling. ChangesLinux process discovery
Estimated code review effort: 3 (Moderate) | ~25 minutes Sequence Diagram(s)sequenceDiagram
participant ForegroundJobLookup
participant ProcMetadataParser
participant CmdlineReader
ForegroundJobLookup->>ProcMetadataParser: Read process-group metadata
ProcMetadataParser-->>ForegroundJobLookup: Return PID, group, command name, and state
ForegroundJobLookup->>CmdlineReader: Read command arguments when safety checks pass
CmdlineReader-->>ForegroundJobLookup: Return command arguments or no result
Possibly related PRs
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Comment |
Greptile SummaryThe PR avoids potentially blocking remote-memory-backed procfs reads on WSL while retaining argv inspection for wrapper processes.
Confidence Score: 5/5The PR appears safe to merge, with no concrete changed-code failure identified. The guarded paths preserve argv inspection for wrappers while avoiding remote-memory-backed procfs reads for known WSL agents and unsafe process states, and the added tests cover the principal branching behavior.
|
| Filename | Overview |
|---|---|
| src/platform/linux.rs | Adds WSL-aware procfs read guards, process-state propagation, cached platform detection, and unit tests without an established actionable defect. |
Flowchart
%%{init: {'theme': 'neutral'}}%%
flowchart TD
A[Read proc stat] --> B{State permits remote-memory read?}
B -- No --> E[Use comm only]
B -- Yes --> C{Running inside WSL and comm identifies agent?}
C -- Yes --> E
C -- No --> D[Read cmdline or environ]
D --> F[Build process or agent detection result]
E --> F
Reviews (1): Last reviewed commit: "fix(linux): avoid blocking proc reads fo..." | Re-trigger Greptile
Context
This was encountered on WSL2 while Herdr was managing several Codex panes. After one of the Codex processes became stuck in an uninterruptible or exiting state, Herdr commands repeatedly failed with:
The failure occurred three times in one day. Restarting the affected pane did not reliably clear the stuck process; terminating the WSL distribution was the recovery used in each case.
Inspection showed affected Codex threads blocked in kernel process-exit and virtual-memory paths. Herdr already identified the foreground executable as
codexfrom/proc/<pid>/stat, so reading its remote-memory-backedcmdlineorenvironwas unnecessary and exposed Herdr to the same stall.This PR does not attempt to recover the stuck agent or fix the underlying WSL kernel behavior. It keeps Herdr's process discovery responsive when an already identifiable agent enters that state, while preserving argv inspection for wrapper processes.
Environment
Summary
/proc/<pid>/cmdlinefor known agent executables on WSL, where procfs can block inaccess_remote_vmwhile a multithreaded process exitsnode, and apply the same guard to agent environment hintsValidation
just test-one remote_memoryjust test-one foreground_job_on_wsljust test-one proc_stat_parsingjust lintjust checkthrough formatting, Clippy, 3,149 Rust tests, integration assets, plugin marketplace tests, and Windows target ClippyThe final maintenance-script step of
just checkcould not run locally because this machine provides Python 3.10, whilescripts/agent_detection_manifest_check.pyimports the Python 3.11+ standard-librarytomllibmodule. The other maintenance tests in that invocation completed before the missing-module error; CI provides the repository's supported environment.