The Orange Pi install put the new service straight into a crash-restart
loop: the unit's default --port 3000 collided with a Docker service
already publishing 3000 (Umami; Gitea and friends default there too).
Fresh installs now scan 3000/3001/3010/3231/3232 via ss and configure
the unit on the first free port, warning loudly when 3000 was taken and
printing the resulting ws:// URL. Upgrades still never touch the unit.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Upgrade path (unit already present): NEVER touch the unit file — it is
the operator's config (SSL, tokens, ports live there as Environment=
lines). Only the binary at the unit's own ExecStart path is replaced,
then the service restarts. Flags/args preserved by construction.
Fresh path (no unit): full first-time setup mirroring the deb postinst
and the agent-service docs — create the socktop system user/group and
/var/lib/socktop, install docs/socktop-agent.service (ExecStart rewritten
to wherever this run installed the agent; embedded fallback for old
refs), daemon-reload, enable --now, and print how to turn on TLS/token.
Also: system-level operations get their own sudo decision (SYS_SUDO) —
previously they inherited the PREFIX sudo flag, so a writable --prefix
made the service section run groupadd/systemctl unprivileged and die.
No sudo at all now skips service management with a warning instead of
failing the install.
Both branches dry-run verified with stubbed systemctl/sudo.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
- Remove zellij_socktop_plugin/target from git (3,577 files committed by
accident in bf6ac87): the root .gitignore anchors /target to the repo
root, so the standalone plugin's own build dir wasn't covered. Ignore
target/ at any depth (also fixes the pre-existing
'/socktop-wasm-test/target' entry, which pointed at a hyphenated path
that doesn't exist).
- install.sh now updates EVERY copy of socktop/socktop_agent on PATH,
not just $PREFIX: a stale 'cargo install' in ~/.cargo/bin shadows
/usr/local/bin on most PATHs, so an install could 'succeed' while
'socktop --version' kept reporting the old release. Extra copies that
can't be written are warned about, not fatal, and the script now
prints which binary is actually active on PATH at the end.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
- Journal pane now distinguishes 'no entries' from 'no journal access':
journalctl exits 0 with empty output when the agent's user simply can't
see the target's entries (demo mode / user-run agents), explaining
itself only on stderr. The agent forwards that hint as an additive
JournalResponse.notice and the client renders it with practical advice.
Verified E2E via a stub journalctl emulating the unprivileged case.
- Version 1.60.0 across all crates (1.51 would read fine, but the repo's
scheme is 1.40/1.50/…, and a literal 1.6.0 would sort BELOW 1.50.0 in
semver). All user-facing version strings already come from
CARGO_PKG_VERSION — a stale binary was the only way to see an old one.
- scripts/install.sh: build-from-source install/upgrade for the test
fleet (Linux + macOS). Detects in-repo checkouts, installs rustup when
missing, replaces a systemd socktop-agent service binary in place and
restarts it, requires system protoc on riscv64.
- build.rs (agent + connector): fall back to $PROTOC / PATH when
protoc-bin-vendored has no binary for the host (riscv64) — native SBC
builds previously panicked in the build script.
- CHANGELOG.md covering v1.50.0 -> 1.60.0.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
jasonwitty