Repository navigation
fix(cli): carry rivetos.service drop-ins over to rivethub.service - #1202
Merged
philbert440 merged 1 commit intoOct 19, 2026
Merged
Conversation
migrate-to-rivethub renders a fresh rivethub.service and never looked at rivetos.service.d/. A node whose service depended on a drop-in lost it in the switch: on a user-scope desktop node that was a Wants/After on the SSH tunnel to the datahub, and a PATH override that keeps ~/.local/bin (Omarchy's mise wrappers, which exec-loop when they precede the mise install dirs) after the tool dirs. The new unit's PATH starts with ~/.local/bin, so the loop would come back. The probe now reads the unit's drop-ins from systemctl show -p DropInPaths, keeping only the persistent files in a rivetos.service.d directory (shared service.d drop-ins already apply to every unit; /run ones are transient). The install step copies them into rivethub.service.d before the first daemon-reload, without overwriting a file of the same name, as root for a system unit. The dry run names them in the step title. Rollback and recovery remove each copy that still matches its source, then the directory if empty.
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
2 participants
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.
migrate-to-rivethubrenders a freshrivethub.serviceand never looks atrivetos.service.d/, so any drop-in the old unit depended on is lost in the switch.Hit this migrating a user-scope desktop node (omarchy).
rivetos.servicehad two drop-ins:datahub-tunnel.conf:Wants=/After=an SSH tunnel unit to the nuc datahub.path-order.conf: aPATHthat keeps~/.local/binafter the mise install dirs. Omarchy's~/.local/binmise wrappers exec-loop when they come first (claude-cli: isAvailable() --version probe has no timeout; a hung claude blocks Runtime.start() indefinitely #831).The rendered unit's
PATHstarts with~/.local/bin, so without the drop-in the loop would return.Change
systemctl show rivetos.service -p DropInPaths(with the user manager for user units). It keeps only*.conffiles in arivetos.service.ddirectory: sharedservice.ddrop-ins already apply to every unit, and/runones are transient.rivethub.service.d/before the firstdaemon-reload, without overwriting a file of the same name. For a system unit the copy runs as root throughsudo -n sh -c. The dry run names them in the step title.cmp -s), then the directory if it's empty.Tests
migrate-to-rivethub.test.ts: discovery filter, copy before daemon-reload, root for system units, no change without drop-ins, rollback removal. All 76 tests in the command pass; tsc, eslint and prettier are clean.systemctl --user show … -p DropInPaths --valueoutput format on the node: space-separated absolute paths.