chore(sp-bundle-logs): capture streamer attach log and archive/disk pressure#660
Conversation
…ressure
The raw section already records where frames land and where each reader looks,
but not the two signals behind the most recent field reports:
- the WebSocket streamer's attach log ("Switched to RAW file: …" / "Resync:"),
which pinpoints the wrong-file bug where the streamer tails SEQNO.RAW and only
DEV shows in the Sensors tab
- gzip archive size vs /persistent free space, which reveals a stalled pruner
before it fills the disk and blocks updates
Both are diagnosable from the bundle alone now instead of asking the user to
hand-run probes.
📝 WalkthroughWalkthroughThis PR adds new diagnostic captures to sp-bundle-logs (port 3001 status, sensorStream journal logs, biometrics-archive size/gzip count, disk usage) and reworks scripts/install to dynamically compute SupplementaryGroups (dac, systemd-journal or adm fallback) for the sleepypod.service unit, only emitting the line when groups exist. ChangesBundle Log Diagnostics
Systemd Service Group Configuration
Estimated code review effort: 2 (Simple) | ~10 minutes Possibly related PRs
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Warning Review ran into problems🔥 ProblemsGit: Failed to clone repository. Please run the Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Codecov Report✅ All modified and coverable lines are covered by tests. 📢 Thoughts on this report? Let us know! |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
🧹 Nitpick comments (2)
scripts/bin/sp-bundle-logs (2)
172-173: 📐 Maintainability & Code Quality | 🔵 Trivial | 💤 Low valueConsider
ss -ltnpfor process attribution.
ss -ltnconfirms the port is listening but not which process/PID owns it. Since the goal is diagnosing whether the "right" streamer attached, including-pwould directly show the owning process for cross-checking against the sensorStream journal tail.♻️ Optional enhancement
-capture "raw/ws-3001.txt" bash -c 'ss -ltn 2>/dev/null | grep -q ":3001 " && echo "port 3001 listening" || echo "port 3001 NOT listening"' +capture "raw/ws-3001.txt" bash -c 'ss -ltnp 2>/dev/null | grep ":3001 " || echo "port 3001 NOT listening"'🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@scripts/bin/sp-bundle-logs` around lines 172 - 173, The port-check captured by the `capture` call for `raw/ws-3001.txt` only verifies that port 3001 is listening, but it does not identify the owning process. Update the `ss` invocation in this log bundle step to include process attribution so the output can be cross-checked against the `sensorStream` journal tail; keep the existing `capture` structure and related `journalctl` capture unchanged.
173-173: 🎯 Functional Correctness | 🔵 Trivial | 💤 Low value
journalctl -bonly covers the current boot.If the sleepypod service (or the pod) restarted after the misattachment happened but before the bundle is collected, the relevant
[sensorStream]attach log will already be outside the current boot window and this capture will come back empty. Worth confirming this is intentional given the bundle is meant to catch a currently-reproducing issue, or whether recent-boots-inclusive (-b -1or a--sincewindow) would be more robust.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@scripts/bin/sp-bundle-logs` at line 173, The current `capture` for `raw/sensorstream-log.txt` only reads `journalctl` from the current boot via `-b`, so it can miss the relevant `[sensorStream]` attach log after a restart. Update the `journalctl` invocation in `sp-bundle-logs` to include recent history as intended, such as a recent-boots window or a `--since`-based range, while keeping the existing `grep -iE "[sensorStream]"` and `tail -40` filtering in place.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Nitpick comments:
In `@scripts/bin/sp-bundle-logs`:
- Around line 172-173: The port-check captured by the `capture` call for
`raw/ws-3001.txt` only verifies that port 3001 is listening, but it does not
identify the owning process. Update the `ss` invocation in this log bundle step
to include process attribution so the output can be cross-checked against the
`sensorStream` journal tail; keep the existing `capture` structure and related
`journalctl` capture unchanged.
- Line 173: The current `capture` for `raw/sensorstream-log.txt` only reads
`journalctl` from the current boot via `-b`, so it can miss the relevant
`[sensorStream]` attach log after a restart. Update the `journalctl` invocation
in `sp-bundle-logs` to include recent history as intended, such as a
recent-boots window or a `--since`-based range, while keeping the existing `grep
-iE "[sensorStream]"` and `tail -40` filtering in place.
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro
Run ID: 0e16c0d0-4a6c-4a3b-af5d-7bb867c5929d
📒 Files selected for processing (2)
scripts/bin/sp-bundle-logsscripts/install
879a892 to
71859db
Compare
|
🎉 This PR is included in version 2.5.0 🎉 The release is available on GitHub release Your semantic-release bot 📦🚀 |
1 participant
Why
sp-bundle-logsalready captures the RAW routing (where frames land, where each reader looks, tmpfs state), but two live field reports needed signals it didn't collect:SEQNO.RAW(the 16-byte counter) instead of a real capture. The tell is insleepypod.service's log:[sensorStream] Switched to RAW file: SEQNO.RAWfollowed byResync:spam. Not previously in the bundle./persistentfull, update fails with No space left on device" — a stalled biometrics pruner letting the gzip archive grow unbounded. The bundle recorded the pruner's journal but not the archive size vs. disk free, so the smoking gun wasn't obvious.Change
Two probes appended to the existing
raw/section:raw/ws-3001.txt+raw/sensorstream-log.txt— is the streamer WS server up, and what did it last attach to (+ any resync spam).raw/archive-size.txt—du -shof the cold archive, gz file count, anddf -h /persistentside by side.No new dependencies; all best-effort under the existing
capturehelper. Pruner/archiver journals continue to come from thejournals/section.Test plan
bash -nclean.bash -csnippets smoke-tested locally (archive-size probe emits count + df; sensorStream grep is a no-op on a non-pod).sp-bundle-logs, confirmraw/ws-3001.txt,raw/sensorstream-log.txt, andraw/archive-size.txtare populated.🛏️ Beam this PR onto a sleepypod ✨
Pick the snippet that matches your pod. Already-installed pods can't use the curl bootstraps below — sleepypod's egress firewall DROPs github.com, and the script that knows how to unblock WAN is the very file curl is trying to fetch. Use
sp-updateinstead; it's on disk and opens WAN as its first step.🔄 Already on a sleepypod (most common — review a PR on a running pod):
🚀 Fresh pod / first install — bootstraps from GitHub, rebuilds every push:
curl -fsSL https://raw.githubusercontent.com/sleepypod/core/chore/sp-bundle-logs-streamer-retention/scripts/install \ | sudo bash -s -- --branch chore/sp-bundle-logs-streamer-retention🎯 Pin to this exact build (run 28831420964 ·
71859db) — fresh-pod path, locked to one CI artifact for reproducible review:🧊 Artifact:
sleepypod-core· self-destructs in 30 days 💥Summary by CodeRabbit
New Features
Bug Fixes