jason
4c59716610
Build Debian Packages / Build .deb for x86_64-unknown-linux-gnu (push) Has been cancelled
Build Debian Packages / Build .deb for aarch64-unknown-linux-gnu (push) Has been cancelled
Build Debian Packages / Build .deb for armv7-unknown-linux-gnueabihf (push) Has been cancelled
Build Debian Packages / Build .deb for riscv64gc-unknown-linux-gnu (push) Has been cancelled
CI / build (ubuntu-latest) (push) Has been cancelled
CI / build (windows-latest) (push) Has been cancelled
Build Debian Packages / Combine all .deb packages (push) Has been cancelled
Build Debian Packages / Publish to APT Repository (push) Has been cancelled
Build Debian Packages / Create GitHub Release (push) Has been cancelled
* fix(agent): drop processes that no longer exist
`refresh_processes_specifics` was called with remove_dead_processes = false
against a long-lived System, so the agent accumulated every process it had
ever seen and went on reporting them. Measured on a Pi 5 after a few hours of
build churn: 21,648 processes reported, 289 actually running, growing a few
every poll.
Three consequences, in ascending order of how confusing they are:
* unbounded memory growth, and every poll iterating ~75x more entries than
it should
* process_count — the client's "Top Processes (N total)" — is meaningless
* a process you kill keeps its row forever, because the agent keeps sending
it. Killing it again reports "no longer exists", since the kernel is
telling the truth and the agent is not.
The third is how this was found: no amount of client-side reconciliation could
fix a list whose producer never forgets anything.
Passing `true` is only correct because these two sites use
ProcessesToUpdate::All. With `Some(pids)` sysinfo treats every process outside
the list as dead and removes it, so the per-PID refresh in
collect_process_metrics must keep `false` — noted in a comment there.
Verified by driving the TUI against a rebuilt agent: reported count 292 vs 290
real, and a killed row is removed once and never reappears.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
* feat(socktop): kill a local process from the TUI
btop-style process termination, for local agents only. The signal is sent by
socktop itself through a direct sysinfo call — nothing is transmitted to the
agent, and the agent and connector have no kill capability at all.
Why local-only: the PIDs on screen are reported by the agent, and the signal is
sent with socktop's own OS privileges. A PID is therefore only meaningful, and
only safe to act on, when the agent lives on this machine; acting on a remote
agent's PIDs would signal whatever unrelated local process happened to share
that number. local::agent_is_local treats an address as local when it is
loopback or when an ephemeral bind succeeds (which only works for an address on
one of our own interfaces, so it also covers reaching our own agent by LAN IP),
requires every address a hostname resolves to to be local, and fails closed.
* `t` on the selected process, and `t` inside Process Details. One key for
both: `k` scrolls the thread table in the modal, so it could not be reused
there.
* The confirmation offers Terminate (focused first, so a reflexive Enter is
the safe one), Force kill, and Cancel. Keeping SIGKILL behind a second
button rather than a second keybinding means the destructive option has to
be chosen deliberately.
* The selection hint gained the key, but only for a local agent — advertising
a key that deliberately does nothing is worse than no hint. Same for the
details modal's help line.
The list is reconciled after a signal rather than left to the next poll. A
signalled PID goes on a watch list re-checked each metrics tick, because SIGTERM
is a request: the process is usually still alive at signal time, and its row
should go when it actually exits (or stay, if it ignores the signal). PIDs
confirmed gone are remembered briefly, since the agent serves Processes from a
1500ms cache and would otherwise hand back a pre-kill snapshot. A selection
whose process has left the list is dropped, and the details view closes for a
process that no longer exists — including when it dies on its own, which
previously flipped that modal to "Agent Update Required" because the wire cannot
distinguish "no such PID" from "endpoint unsupported".
Also fixes two pre-existing UI faults found on the way:
* The selection hint was sized from its full label including the process name
and skipped entirely when that exceeded the pane width — so it vanished
exactly when a long-named process was selected. The name is now the elastic
part, and widths are measured in columns rather than bytes.
* Confirmation and Info dialogs laid their content out over the whole modal
rect instead of the block's inner rect, putting the first line of text on
the border row, and fell into the catch-all 70%x50% sizing arm, so a
one-line question got half the screen. They now size to their content and
use the theme's colors like the connection-error modal does.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
* fix(kill): close stacked details view, guard PID reuse, scale settle with interval
Review fixes for the process-kill feature:
1. Killing from INSIDE the details view left it open forever, frozen on
the dead process (reproduced live): the 'Signal sent' Info modal sits
on top when the death is confirmed on the next tick, the old top-only
close_process_details missed it, gone-PIDs are processed once, and the
details-poll fallback was gated on the selection the kill had just
cleared. The close now removes the dead PID's view wherever it sits in
the stack — which also retires a dead parent's view from under a child
in a navigation chain, so backing out lands on the process list rather
than a frozen corpse view. Tests updated to the new semantics, plus a
regression test for the Info-stacked case.
2. PID-reuse guard: the PID comes from an agent snapshot and the
confirmation can sit open indefinitely, so by signal time the kernel
may have recycled the number. kill_local_process now takes the name
the user confirmed and refuses to signal a PID whose current owner
does not match ('PID N now belongs to X, not Y').
3. A transient request error no longer closes the details view: with
process_details_answered set, any Err was read as 'process gone',
including socket blips. The view now closes only when the PID is also
absent from the agent's own process list.
4. PROC_CACHE_SETTLE scales with the user's processes interval (floor at
the old 1.6s default-TTL value), and the tombstone lifetime rides on
top of it — users who raise the agent's Processes TTL raise the client
interval to match, so the interval is the best client-side signal for
how stale an agent snapshot can be.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
* fix(kill): resume polling for the details view that resurfaces from a chain
Reported: kill still orphaned a window via Enter (child details) -> P
(parent details) -> t (terminate parent). The parent's view closed
correctly, but the child's view underneath resurfaced with no selection
(forget_process_row had cleared it — it pointed at the parent) and wiped
data; the selection-gated details poll never refilled it.
close_details_for_gone_process now retargets the selection to the
uppermost remaining ProcessDetails view (looking through stacked
Info/Confirmation modals) and makes the poll due immediately — the same
retarget SwitchToParentProcess performs on the way down the chain.
Same class of hole in plain navigation, fixed alongside: Esc-ing back
from a parent view left the selection on the PARENT, so the resurfaced
child-titled view refilled with the parent's data. The dismiss arm now
retargets the selection to whatever details view it lands on.
Both verified live: child -> P -> kill parent -> child view resurfaces
populated and updating; child -> P -> Esc -> child view shows the child.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
* docs: changelog section for the process-kill feature and agent dead-process fix
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
---------
Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
5.7 KiB
5.7 KiB
Changelog
1.60.0 — unreleased
Everything since v1.50.0. Applies to all three crates (socktop, socktop_agent, socktop_connector), which move to 1.60.0 together.
Security
- Certificate pinning is now real. With
--verify-hostnameoff (the default), the client previously accepted any server certificate — the--tls-cafile was never consulted. The presented certificate must now be byte-identical to one in the pinned PEM (multi-cert files supported for rotation). If you use TLS, update the client: earlier versions are MITM-able despite the pinning documentation. (housekeeping-p2) key.pemis created with mode 0600 (was world-readable 0644); agents also tighten existing keys on startup. (housekeeping-p2)- The agent's per-PID caches now evict (60s age / 64 entries); previously they grew without bound. (housekeeping-p2)
Performance
- Agent CPU on GPU machines cut ~6× (measured 23.5 → 4.0 ms/s at default polling): GPU collection moved to a dedicated worker thread that keeps the NVML session open instead of re-initializing it every 1.5 s on the async runtime. (housekeeping-p2)
journalctlno longer blocks the agent's async workers. (housekeeping-p2)- Cached "no temp sensor / no GPU" results count as fresh — no more per-request rescans on hosts without them. (housekeeping-p2)
- Nagle disabled on all connection paths (small request/response frames). (housekeeping-p2)
TUI
- Compact layout for small windows: when the window is too short for the Disks pane, Disks is dropped, Memory/Swap go side by side, GPU collapses to one line (omitted if absent), and the reclaimed rows keep the CPU graph and per-core bars visible.
--compactpins it. (#37) - Width-aware text: header, CPU title, and process table shed detail by priority as the terminal narrows instead of overwriting each other; process Name column is now the last to go, not the first. Fixed sort-header clicks landing up to 4 columns off. (#38)
- Responsive input: keys and mouse are handled within ~30 ms instead of queueing for a full metrics interval. (housekeeping-p2)
- No more freezes: all requests carry a 5 s timeout; a dead connection shows the reconnect modal (with working
q) instead of hanging the UI. Consecutive timeouts surface a persistent "agent not responding" error. (housekeeping-p2) - Old agents without the per-process endpoints once again show "Agent Update Required" instead of a reconnect loop. (housekeeping-p2)
- Journal pane distinguishes "no entries" from "no journal access" (e.g. user-run/demo agents) and shows journalctl's hint plus the fix. (housekeeping-p2)
- Scatter-plot axes align correctly for large CPU-time values. (housekeeping-p2)
- Demo mode explains how to install
socktop_agentwhen the binary is missing. (#36)
Correctness
- Process/child CPU times were sent as ms but displayed as µs — values rendered 1000× too small in the details modal. (housekeeping-p2)
- Non-Linux per-process CPU% no longer truncates multi-core usage (clamp after divide). (housekeeping-p2)
- Journal timestamps are real RFC 3339 UTC with numeric sorting (additive
timestamp_us). (housekeeping-p2) - Partition detection uses
/sys/blockon Linux — whole-disk filesystems (nvme0n1,zram1) are no longer misclassified as partitions. (housekeeping-p2) - Network rates use agent-side sample timestamps (additive
sampled_at_ms), eliminating rate sawtooth from TTL-cached snapshots; falls back to the client clock with older agents. (housekeeping-p2) - The details modal's Command/exe/cwd fields are populated again (dropped by an earlier refresh optimization). (housekeeping-p2)
- Non-ASCII device names no longer panic the disk pane. (housekeeping-p2)
Wire format (additive only — old/new client-agent pairs keep working)
Metrics.sampled_at_ms(epoch ms of actual collection)JournalEntry.timestamp_us(epoch µs),JournalEntry.timestampnow RFC 3339JournalResponse.notice(journal-access hint)
Internal / packaging
- ratatui 0.28 → 0.30 (#33); aws-lc-rs advisories patched (#34); Debian packaging for the agent (#25); assorted dependabot bumps.
- ~3,100 lines of dead code removed, including an orphaned pre-refactor copy of the connector.
socktopconsumessocktop_connectorvia a path+version dep — connector changes are testable in-repo before publishing.- wasm examples build against the in-repo connector; note
zellij_socktop_pluginhas pre-existing compile errors and needs its own rework.
Process kill (PR #40)
- Kill a local process from the TUI (
ton a selected process, or inside Process Details): btop-style Terminate/Force-kill confirmation. Local agents only — the signal is sent by socktop itself with its own privileges, never over the wire; remote agents never show the option. PID-reuse guarded (the confirmed name must still own the PID at signal time). - Agent no longer reports dead processes: a long-lived sysinfo
Systemaccumulated every process ever seen (21k+ entries on a 289-process host), inflating memory, per-poll work, and the process count — and keeping killed processes on screen forever. Update agent and client together on machines where the kill feature will be used. - Killed rows leave the list when the process actually exits and cannot be resurrected by cached agent snapshots; details views for dead processes close themselves, including through parent-navigation chains.
- Selection hint no longer vanishes for long process names; confirmation/info dialogs size to their content.
Upgrade notes
- Release/publish order:
socktop_connector→socktop→ agent packages. - Clients older than 1.60 work against 1.60 agents and vice versa; the security fix is client-side, so prioritize client updates where TLS is used.