fix(services): create working_dir and accept a keg name - #797
Open
rustytrees wants to merge 1 commit into
Open
Conversation
Two independent bugs, both hit by `malt services start mosquitto`. **`ServiceNotFound` on a service that `services list` shows.** Services are registered under their launchd label (`com.malt.mosquitto`) while `keg_name` holds the formula (`mosquitto`), and the lifecycle lookup queried `name` only. Every other verb takes the formula name — `install mosquitto`, `uninstall mosquitto` — so the one place that demanded the label was the one place a user would not think to look it up. `resolveLabel` now accepts either. The label still wins outright, so an exact request is never reinterpreted, and a formula registering two services says so instead of picking one. `hasService` matches the same way so `status` and `start` agree on what exists. **Registered services whose working_dir does not exist cannot start.** launchd fails the spawn with EX_CONFIG (78) *before* exec when WorkingDirectory is missing, so StandardErrorPath is never created either: the user gets a bare "errored" and an empty log directory, with nothing anywhere saying which path was wrong. `cli/install.zig` already pre-creates the log directory for exactly this reason — the working dir was the half that got missed, and nothing else in the install path creates it. mosquitto is a plain example: it declares `working_dir var/mosquitto`, has no post_install, and its install step is a bare cmake install, so that directory never exists on a fresh install. `plist_mod.validate` has already confined the path to the keg or the prefix by the time we get here, so creating it is in-bounds. Both regression tests fail against the previous code — the working_dir one with FileNotFound, which is the same shape as the real failure.
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.
Fixes #796 — both halves.
resolveLabel: accept either nameServices are stored under their launchd label with the formula in
keg_name, and the lifecycle lookup queriednameonly. Now either resolves, with three properties I thought were worth pinning rather than assuming:keg_name, an exact request is never reinterpreted.postgresql@16→ two labels) returnsAmbiguousServiceand tells you to name one, instead of silently picking the first row.hasServicematches the same way, sostatusandstartagree on what exists — otherwisestatus mosquittowould still say "no such service" for somethingstart mosquittocould now act on.register: createworking_dirThree lines, guarded by the fact that
plist_mod.validatehas already confined the path to the keg or the prefix by that point, socreateDirPathcannot be aimed outside.cli/install.zigalready does this for the log directory; this is the same treatment for the other declared path.The failure mode is what makes this worth fixing rather than documenting: launchd returns
EX_CONFIGbefore exec, soStandardErrorPathnever gets created and the user is left witherrored, an empty log directory, and no indication of which path was wrong. I lost a while to it on a real install before thinking to checklaunchctl list.Deliberately not included
Seeding a missing config file named by a
service.runargument. mosquitto also needsetc/mosquitto/mosquitto.conf, which nothing creates — but inventing config content is a different class of decision from creating a directory the plist already declares, and I did not want to smuggle it in here. Flagged in #796 if you want it.Verification
zig build test— full suite green./scripts/lint-spawn-invariants.sh— clean./scripts/smokes/smoke_security.sh— 8/8 (touches the plist validator's neighbourhood)Four regression tests, and I checked they fail against the current code rather than passing vacuously — the
working_dirone fails withFileNotFound, which is the same shape as the real failure.