Repository navigation
fix: keel-overlay-vip ships every unit off on the first installation - #44
Merged
Merged
Conversation
keel-vip-check.timer was installed with plain dh_installsystemd, whose was-enabled defaults to true on a first installation and which does not read the preset, so a standalone machine ran keel vip check every minute. Every other overlay leaves its units off until keel spec apply enables the overlay (handbook decision 0041). The timer now has no [Install]; keel-vip.service wants it and the timer is PartOf the controller. keel enables the units the manifest names (keel-vip.service), so the check runs exactly while the VIP is enabled and stops with it; disabling the timer alone would have left it never running. Both units are installed with --no-enable --no-start and both are disabled in the preset. keel-overlay-vip 0.1.1. tests/overlay-install.bats installs the package on the booted trixie container of the install job with the other four overlays: keel-vip.service is disabled and inactive with the rest, the timer is static and inactive, PartOf the controller and wanted by it, and the preset names both. The job builds keel at befaaea (0.20.0, Keel-Linux/keel#81), which the package depends on.
added 3 commits
October 7, 2026 23:32
…ian does not read it as an NMU
The previous commit cut the file at the first occurrence of the install section's name, which was in the new comment, so the timer shipped with no PartOf and no [Timer]; tests/overlay-install.bats caught 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.
keel-vip-check.timerwas enabled on install bydh_installsystemd(was-enableddefaults to true; the preset is not read), so a standalone machine rankeel vip checkevery minute. All other overlays leave their units off untilkeel spec applyenables the overlay (decision 0041).[Install]:keel-vip.serviceWants=it and the timer isPartOf=the controller. keel enables what the manifest names (keel-vip.service), so the check runs exactly while the VIP is enabled; disabling the timer alone would have left it never running.--no-enable --no-start, both disabled in the preset. keel-overlay-vip 0.1.1.tests/overlay-install.bats(install job, booted trixie container):keel-vip.servicedisabled and inactive; the timer static and inactive, PartOf and wanted by the controller; the preset names both. The job's keel pin moves to befaaea (0.20.0), which the package depends on.Also checked the other overlays for the same pitfall: only
keel-overlay-coraza-logrotate.timer(WantedBy=timers.target, plain dh_installsystemd, no preset) is enabled on install, harmless but not "off"; etcd and crowdsec disable in postinst with a preset, anubis' key unit is static, wireguard and installer ship no units. Not changed here.