clivisor

Overview ¶

Package clivisor cmd/skywire-cli/commands/visor/app.go c4-vis-cli

Package clivisor cmd/skywire-cli/commands/visor/cxo.go c4-vis-cli introspection for the visor's lazy-on-demand CXO subscription manager. Three subcommands:

• cxo status per-feed snapshot/refcount/last-sync/last-err
• cxo refresh <feed> force a synchronous subscribe + first-Root + walk
• cxo fetch <feed> <path> [opts] hit FetchCXO directly, dump body or miss reason

Useful when a higher-level command (`tp -m`, `proxy list`, …) shows missing data and you want to know whether the CXO snapshot has it (so the gap is in the higher-level rendering) or doesn't (so the snapshot is genuinely empty / the publisher is unreachable).

Package clivisor cmd/skywire-cli/commands/visor/cxo_feeds.go c4-vis-cli

`skywire cli visor cxo` — surface for the user-publishable CXO TreeStore feeds. Each feed is its own DMSG listener under the visor's PK; subscribers connect to (visor PK, feed.dmsg_port) and receive the published path tree.

Discovery happens out-of-band via the dmsghttp logserver's /feeds endpoint (and via this CLI which calls the same data source over RPC).

Package clivisor cmd/skywire-cli/commands/visor/doctor.go c4-vis-cli visor doctor` rolls a healthy-or-not verdict + the underlying signals into one command. Today an operator answers "is this visor healthy?" by running five commands (visor info, tp ls, rg ls, dmsg diag, svc health) and reading skychat /status separately — doctor collapses that into a single output with a GREEN / YELLOW / RED top-line verdict and the per-subsystem breakdown.

No new visor RPC surface — composes existing Summary + the chat-app's HTTP /status endpoint. Skychat is queried best-effort: when the app isn't running or the address is wrong, doctor still returns the visor-side verdict and notes the skychat probe error in the JSON output.

Package clivisor cmd/skywire-cli/commands/visor/exports.go c4-vis-cli

Exposes visor subcommand handlers so the top-level shortcuts (cli pk, cli status, cli halt) can delegate Run without sharing the *cobra.Command instance. Each shortcut wraps one of these so the help template renders correctly under both parents — root and `cli visor` use different group taxonomies, and a single Command can only carry one GroupID.

Package clivisor cmd/skywire-cli/commands/visor/goroutines.go c4-vis-cli fetches and summarizes the visor's pprof goroutine dump. Replaces the manual `curl + awk + grep` ritual for diagnosing visor hangs (RPC timing out, transport.Manager deadlocks, syncMu pile-ups, etc.).

Three views:

• summary (default): counts per state, top stack heads, lock waiter summary, a likely-holder heuristic for tm.mx-style RWMutex pile-ups.
• --full: dump the raw pprof text to stdout (or --out).
• --filter <re>: only goroutines whose stack body matches the regex; combined with --full this slices a huge dump down to "show me only ManagedTransport readLoops" sized output.

Package clivisor cmd/skywire-cli/commands/visor/hostbridge.go c4-vis-cli

Package clivisor cmd/skywire-cli/commands/visor/hv.go c4-vis-cli

Package clivisor cmd/skywire-cli/commands/visor/hv_auth.go c4-vis-cli

Package clivisor cmd/skywire-cli/commands/visor/hv_map.go c4-vis-cli

Package clivisor cmd/skywire-cli/commands/visor/hvtui.go c4-vis-cli

Package clivisor cmd/skywire-cli/commands/visor/info.go c4-vis-cli

Package clivisor cmd/skywire-cli/commands/visor/ip.go c4-vis-cli

Package clivisor cmd/skywire-cli/commands/visor/pair.go c4-vis-cli

`skywire cli visor pair` — drive the visor's chat-pair feed manager from the CLI. Handy for testing the pairing pipeline without running the skychat app, and for scripted setups where pairs are bootstrapped from config (e.g. seed-pair lists in integration tests).

Each subcommand wraps one Visor.Pair* RPC method:

pair add <peer-pk>          → PairAdd
pair ls                     → PairList
pair rm <peer-pk>           → PairRemove
pair send <peer-pk> <text>  → PairSend
pair poll [--since <RFC3339>] → PairPoll

Package clivisor cmd/skywire-cli/commands/visor/process.go c4-vis-cli

Package clivisor cmd/skywire-cli/commands/visor/proxies.go c4-vis-cli

`skywire cli visor proxies` — status command for the visor-hosted resolving proxies (dmsgweb, skynetweb). Two subcommands:

proxies          status + stats table (or --json)
proxies set      toggle a resolver on/off at runtime

No enable/disable is persisted to disk — runtime state only. That keeps the CLI useful for "try this setting" experiments without touching the on-disk config.

Package clivisor cmd/skywire-cli/commands/visor/reinit.go c4-vis-cli

Package clivisor cmd/skywire-cli/commands/visor/reward.go c4-vis-cli

Package clivisor cmd/skywire-cli/commands/visor/root.go c4-vis-cli

Package clivisor cmd/skywire-cli/commands/visor/services.go c4-vis-cli

Package clivisor cmd/skywire-cli/commands/visor/skyenv.go c4-vis-cli

Package clivisor cmd/skywire-cli/commands/visor/state.go

Package clivisor cmd/skywire-cli/commands/visor/uptime.go c4-vis-cli the visor's own session-history (started_at, last_seen, version per process incarnation) recorded by pkg/serviceuptime. Pulls data via the visor RPC's UptimeHistory method, so works whether or not the visor's logserver is reachable from the CLI host.

Package clivisor cmd/skywire-cli/commands/visor/user.go c4-vis-cli

Package clivisor cmd/skywire-cli/commands/visor/whois.go c4-vis-cli visor whois <pk>` — single-PK rollup combining transport-discovery and service-discovery state into one report.

Today an operator answering "what do we know about this visor PK" has to hit two separate services:

cli tp ls --remote <pk>      — transports the visor is on
cli sd | grep <pk>           — services the visor advertises

whois collapses those into one report. Useful when triaging a peer from a log entry, a chat message, or a transport-id: paste the PK, see everything the discovery layer knows about it.

Best-effort: each lookup runs independently and timeouts are per-service. A service being down marks its block as "unreachable" in the report and doesn't fail the whole command.

Package clivisor cmd/skywire-cli/commands/visor/zgroups.go c4-vis-cli

Groups the subcommands of `skywire cli visor` so the help output renders as discoverable sections instead of a flat wall. Filename starts with `z` so this init runs AFTER the per-feature files' inits (Go runs init functions in the order source files are compiled, alphabetically within a package) — by then every subcommand has been AddCommand'd and we can assign GroupIDs by name in one place.

Every non-hidden, non-deprecated subcommand MUST appear in the commandGroup map below. The shared help template in pkg/flags (helpTemplateNoUsage / help) renders ONLY grouped commands once any group is defined — it does NOT emit cobra's default "Additional Commands:" block — so a command left out of the map is registered and callable but invisible in `visor --help`. Keep this map in sync when adding a subcommand.