Repository navigation
fix: the first boot's security updates never hold it - #41
Merged
Merged
Conversation
95secupdates ran apt-get update and the upgrade with no limit, so a stalled mirror or a hung maintainer script held every hook after it. apt-get update now runs within SEC_UPDATES_UPDATE_TIMEOUT (120 s) and the whole run within SEC_UPDATES_TIMEOUT (900 s), both overridable from the inithooks conf. A run stopped or failed leaves dpkg configured (dpkg --configure -a when dpkg --audit reports anything), records nothing and writes one line to the inithooks log naming cron-apt, the daily job that installs the updates instead. No network still exits 0; a stopped or failed upgrade exits 1, which run logs before going on to the next hook.
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 maintainer's decision: an unattended first boot installs the security updates (SEC_UPDATES=FORCE,
security.updates_at_first_boot: force), but they must never block the boot.What changes in
firstboot.d/95secupdatesapt-get updateruns withinSEC_UPDATES_UPDATE_TIMEOUT(default 120 s), and the whole run (dpkg --configure -a, update, autoclean, dist-upgrade fromsecurity.sources) withinSEC_UPDATES_TIMEOUT(default 900 s). Both are read from the inithooks conf; a value that is not a whole number of seconds is said in the journal and the default is used.timeoutsignals apt's whole process group (dpkg and maintainer scripts too), SIGKILL 30 s after SIGTERM. Stdin is/dev/null.dpkg --configure -aruns (bounded, 300 s) whendpkg --auditreports anything, so dpkg is not left half configured.WARN: [95secupdates] security updates not installed: <why>; the boot goes on and cron-apt installs them at its daily run. cron-apt is what the images ship (Keel-Linux/commonplans/turnkey/base,conf/turnkey.d/cronapt; no unattended-upgrades). The hook checks for cron-apt's install action/etc/cron-apt/action.d/5-installand namesturnkey-install-security-updatesinstead when it is missing.apt-get updatefailed or stopped: 0, as before. Upgrade stopped or failed: 1, whichrunlogs as failed and then goes on to the next hook.Tests
tests/test-secupdates.batsgains 12 tests with fake apt-gets that hang, fail or succeed: each hang is stopped within its limit (timed, under an outertimeoutso a regression fails instead of hanging the suite), dpkg is configured after a stopped upgrade, the one log line names cron-apt, and three tests go through the realrunto show the hook after 95secupdates still runs (hung upgrade, failed upgrade, offline). Against the old hook, 10 of them fail and the hungruntest times out.Coverage:
95secupdates110/111 (the Hub status call is the one line not run), shell total 99.71. The changelog entry is 2.3.6+keel23, added on top.