morluto/rea

Fork 0

mirror of https://github.com/morluto/rea.git synced 2026-11-05 06:45:22 +00:00

[GH-ISSUE #3757] Firmware tools need procps ps, which their requirements do not list #1461

New issue

Closed

opened 2026-10-16 21:05:38 +00:00 by bsakaguchi · 3 comments

bsakaguchi commented

2026-10-16 21:05:38 +00:00

Owner

Originally created by @oleander on GitHub (Oct 14, 2026).
Original GitHub issue: https://github.com/morluto/rea/issues/3757

Summary

The firmware integrations (inspect_firmware_regions and extract_firmware) need a procps-compatible ps on rea's PATH. The tool descriptions do not say so, and rea doctor does not check it.

Environment

rea-agents 6.5.0, linux-arm64, in a minimal Debian bookworm image (node:22.23.2-bookworm-slim), which ships without procps.

Observed

With binwalk, unblob and prlimit installed and the REA_*_COMMAND variables set, both commands fail before running the tool:

{"ok":false,"error":{"code":"capability_unavailable","category":"unsupported_provider","message":"Linux process ownership inspection requires a procps-compatible ps on REA's PATH before launching a child: spawn ps ENOENT", "details":{"provider_id":"process-ownership","operation":"prepare_owned_process"}}}

After apt-get install procps, both commands work.

Expected

The runtime message is clear, but the requirement only shows up after a failed run. The tool descriptions list "Linux, caller-supplied tool and util-linux prlimit required" for both tools. Adding ps (procps) to that list, and to the setup docs, would let a container recipe get it right the first time. Slim and distroless images usually lack procps.

Suggested priority: P3: low (I cannot set labels on this repo).

Originally created by @oleander on GitHub (Oct 14, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/3757 ## Summary The firmware integrations (`inspect_firmware_regions` and `extract_firmware`) need a procps-compatible `ps` on rea's PATH. The tool descriptions do not say so, and `rea doctor` does not check it. ## Environment rea-agents 6.5.0, linux-arm64, in a minimal Debian bookworm image (`node:22.23.2-bookworm-slim`), which ships without procps. ## Observed With binwalk, unblob and prlimit installed and the `REA_*_COMMAND` variables set, both commands fail before running the tool: ```json {"ok":false,"error":{"code":"capability_unavailable","category":"unsupported_provider","message":"Linux process ownership inspection requires a procps-compatible ps on REA's PATH before launching a child: spawn ps ENOENT", "details":{"provider_id":"process-ownership","operation":"prepare_owned_process"}}} ``` After `apt-get install procps`, both commands work. ## Expected The runtime message is clear, but the requirement only shows up after a failed run. The tool descriptions list "Linux, caller-supplied tool and util-linux prlimit required" for both tools. Adding `ps` (procps) to that list, and to the setup docs, would let a container recipe get it right the first time. Slim and distroless images usually lack procps. Suggested priority: P3: low (I cannot set labels on this repo).

bsakaguchi commented

2026-10-16 21:05:39 +00:00

Author

Owner

@XinwangTao commented on GitHub (Oct 15, 2026):

Confirmed on a minimal base image too — the procps dependency is genuinely easy to miss because it only surfaces at first failed run with a spawn ENOENT. Listing ps (procps) alongside "Linux, caller-supplied tool and util-linux prlimit" in both tool descriptions, plus a line in setup docs that slim/distroless images usually lack procps, would fix the bootstrap experience for container recipes. Also worth considering: doctor already gained a firmware section suggestion (#3758); adding a procps/ps check there would catch this before any run instead of after.

@XinwangTao commented on GitHub (Oct 15, 2026): Confirmed on a minimal base image too — the procps dependency is genuinely easy to miss because it only surfaces at first failed run with a spawn ENOENT. Listing ps (procps) alongside "Linux, caller-supplied tool and util-linux prlimit" in both tool descriptions, plus a line in setup docs that slim/distroless images usually lack procps, would fix the bootstrap experience for container recipes. Also worth considering: doctor already gained a firmware section suggestion (#3758); adding a procps/ps check there would catch this before any run instead of after.

bsakaguchi referenced this issue

2026-10-17 21:11:36 +00:00

[PR #1461] [MERGED] fix(mcp): validate doctor probe against its discovered output contract #2902

bsakaguchi closed this issue

2026-10-31 00:30:50 +00:00

bsakaguchi commented

2026-10-31 00:30:51 +00:00

Author

Owner

@morluto commented on GitHub (Oct 26, 2026):

Thanks for documenting the minimal-container failure. The current firmware tool descriptions name procps ps, and the installation and firmware guides explain the shared Linux prerequisite and package names. The separate firmware doctor request remains open as #3758. I am closing this documentation request as addressed; please reopen if a required description or setup instruction is still missing. This was checked from source, without rerunning the container.

@morluto commented on GitHub (Oct 26, 2026): Thanks for documenting the minimal-container failure. The current firmware tool descriptions name procps `ps`, and the installation and firmware guides explain the shared Linux prerequisite and package names. The separate firmware doctor request remains open as #3758. I am closing this documentation request as addressed; please reopen if a required description or setup instruction is still missing. This was checked from source, without rerunning the container.

bsakaguchi commented

2026-10-31 00:30:51 +00:00

Author

Owner

@XinwangTao commented on GitHub (Oct 27, 2026):

Understood — if #5794 / #7041 already cover the Binary Ninja integration paths, closing this as not planned is reasonable. If the binary-analysis use case grows, a follow-up that surfaces discovered Binary Ninja instances (analogous to list-browser-targets) would be the natural increment.

@XinwangTao commented on GitHub (Oct 27, 2026): Understood — if #5794 / #7041 already cover the Binary Ninja integration paths, closing this as not planned is reasonable. If the binary-analysis use case grows, a follow-up that surfaces discovered Binary Ninja instances (analogous to list-browser-targets) would be the natural increment.

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

morluto/rea#1461

No description provided.

Rows
Columns