fix: keep workers disarmed at boot while autostart is off - #1534
Open
geodro wants to merge 2 commits into
Open
Conversation
Enabling a worker armed its systemd unit for login start no matter what the autostart switch said. Turning autostart off disabled every unit on disk at that moment, but anything written afterwards, a worker enabled in the dashboard, a unit rewritten by lerd start, went back to being wanted by default.target. At the next boot systemd started it, BindsTo pulled the FPM container up with it, and nothing pulled up the databases and caches behind it, so the worker died on a connection error and Restart=always looped it for as long as the session lasted. Arming a worker unit now goes through one place that consults the autostart flag and disarms instead when it is off, which also clears an arming left behind by an older build. The unit is still started by whoever asked for it, so a worker that should be running now still runs. On macOS launchctl enable is also what lifts the flag that blocks bootstrapping a label at all, so the gate stays out of that path and the platform keeps its current behaviour. Two places read "is the unit enabled" as "does the user want this worker", which that flag no longer answers once a running worker can be disarmed. The PHP image rebuild now snapshots which workers were up before it restarts FPM and brings exactly those back, rather than trusting the enable state it had just invalidated. A node runtime switch regenerates the unit of a worker that is merely running, not only an armed one.
The arming guard now treats a running worker as installed, so it reaches for IsActive whenever IsEnabled comes back false. The double in the regeneration test only answered IsEnabled and embedded a nil manager for everything else, which left that second call landing on the nil interface and taking the process down with it.
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.
Enabling a worker armed its systemd unit for start at login regardless of the autostart switch.
lerd autostart disabledisabled every unit that was on disk at that moment, but anything written afterwards went straight back to being wanted bydefault.target: a worker enabled in the dashboard, or a unit rewritten by a laterlerd start. So a machine with autostart off still tried to run that worker at every boot.What the reporter saw follows from there. Horizon came up at login,
BindsTopulled the FPM container along with it, and nothing pulled up Redis, whose quadlet correctly has its[Install]section stripped while autostart is off. Horizon died ongetaddrinfo for lerd-redis failed,Restart=alwaysbrought it back, and the loop ran for the whole session, filling the journal.Arming a worker unit now goes through a single place that consults the autostart flag, and disarms the unit instead when the flag is off. Disarming also clears an arming an older build left behind, so an install that is already looping heals itself the next time that worker's unit is written, without the user having to know that toggling autostart off a second time would have fixed it. Nothing about starting changes: callers start the unit themselves, so a worker that should be running right now still runs.
On macOS
launchctl enableis also what lifts the flag that blocks bootstrapping a label at all, so skipping it would stop a worker from starting now rather than only at the next login. A platform var keeps the autostart flag out of that path, and macOS behaviour is unchanged.Two other places were reading "is the unit enabled" as "does the user want this worker", which stops being a fair proxy once a running worker can sit disarmed. The PHP image rebuild now snapshots which workers were up before it restarts FPM and brings exactly those back, instead of trusting an enable state that the restart had just invalidated, which also means it stops resurrecting workers the user had deliberately stopped. A node runtime switch now regenerates the unit of a worker that is merely running, not only of an armed one.
The four MCP tools that write their own worker units follow the same rule through a helper in the systemd package.
Refs #1531