discover
discover lists the Xray runtime targets that RayLimit can currently see through its discovery service.
Basic Usage
raylimit discover
raylimit discover --format jsonWhat The Command Is For
Discovery is the top of the operator workflow. It gives you:
- runtime identity
- host-process or container source data
- provider errors when a discovery backend could not complete cleanly
It answers one question only: “what runtimes can RayLimit see right now?”
What To Do With The Result
Use discover to choose the selector you will pass to inspect or limit:
sudo raylimit discover
sudo raylimit inspect --pid 1234
sudo raylimit limit --pid 1234 --ip all --device eth0 --direction upload --rate 4096When To Use JSON
Use JSON when you need:
- another script to select a target
- a saved runtime inventory snapshot
- a machine-readable input to later validation or orchestration
How Detection Works
Discovery recognizes both vanilla Xray and the Sanaei fork through prefix-matched binary names, plus container image, command, label, and published-port signals. The full detection and binary-resolution rules live in Runtime Targeting; discovery is where those signals first surface.
Point discovery at a fork binary installed at a non-standard path:
sudo raylimit discover --xray-binary /opt/sanaei/sanaei-linux-amd64Scan containers under a non-default CLI:
sudo raylimit discover --container-cli podmanWhen running containers are scanned but none match any Xray signal, discovery records a no_matches limitation. It is informational, not fatal: host-process results (and other sources) are still returned.
Provider Errors And Partial Results
Discovery can still return useful runtime data even when one provider reports an error. Read provider errors as a signal that one discovery path is incomplete, not as proof that every runtime is unusable.
What discover Does Not Do
discover does not:
- modify the host
- derive limiter selectors
- infer whether a limiter path is concrete
- compare existing
tcstate
Those steps belong to inspect and limit.