fix(cli): restart the daemon on update, so a new build actually takes effect - #173
Merged
Conversation
… effect Updating the CLI replaced files on disk and nothing else. A daemon that was already running kept executing the bundle it was spawned from — on one host, 0.11.3 out of a pnpm store path for a version that was no longer installed at all — while the CLI beside it reported 0.11.6 and every `update` printed "✓ ThreatCrush updated successfully!". Nothing in the output hinted that the thing actually serving traffic had not moved. `update` and install.sh now bring the daemon onto the new build, and say so. Restarting it is not unconditional: a systemd-managed daemon must go through systemd, because `threatcrush restart` there stops the supervised copy and starts an unsupervised one in its place. We detect that by comparing the unit's MainPID against the running daemon and hand over `systemctl restart` instead. After a restart the daemon's reported version is compared against the CLI's, so a daemon that somehow stayed behind is now stated rather than assumed. Also note that an open `monitor --tui` holds the old code until it is relaunched — it loads at launch, which is its own way of looking like a failed upgrade. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_018NXz7vRz6C7vaGSwMgWZfD
ThreatCrush Security Scan12 finding(s) HIGH/CRITICAL: 1 | MEDIUM: 6 | LOW: 5
Snippets are redacted; ThreatCrush never prints matched credential material. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The gap
threatcrush updatealready did the hard parts — installs@latest(defeating both the range-boundupdate -gand pnpm's global lockfile pin), updates every package manager holding a copy, and warns when PATH still resolves somewhere older.It never touched the daemon. Updating the CLI replaces files on disk and nothing else, so a daemon already running keeps executing the bundle it was spawned from. On one host that was 0.11.3 out of a pnpm store path for a version no longer installed at all, while the CLI beside it reported 0.11.6 and every
updateprinted✓ ThreatCrush updated successfully!. Nothing in the output hinted the thing actually serving traffic hadn't moved.Change
updateandinstall.shnow bring the daemon onto the new build and say so.threatcrush restartthere stops the supervised copy and starts an unsupervised one systemd knows nothing about. Detected by comparing the unit'sMainPIDagainst the running daemon; we hand oversudo systemctl restart threatcrushdinstead.monitor --tuiholds the old code until relaunched — it loads at launch, which is its own way of looking like a failed upgrade.Verification
Tested against a genuinely stale daemon, not a mock. The dev box had CLI 0.11.7 beside a daemon on 0.11.4:
threatcrush statusthen reportedVersion: 0.11.7.The systemd branch was checked against the live supervised daemon on the other host:
MainPID=1150300equals its pidfile, so detection returns managed and it hands over the systemctl command rather than restarting.pnpm test— 73 passed (7 files), up from 62.pnpm buildclean;sh -n install.shPOSIX-valid.🤖 Generated with Claude Code
https://claude.ai/code/session_018NXz7vRz6C7vaGSwMgWZfD