Repository navigation
Keep the post-update setup off the boot path, and stop the web seeder holding the boot - #125
Merged
Merged
Conversation
… holding the boot After every kit update the first boot runs optimize-boot.sh for about 60 s in the background (22 daemon-reloads, every drop-in rewritten), at default priority, on the same two cores every service shares. Measured 2026-09-05 on the dev printer: a Spoolman cold start stretched to 46 s, Moonraker -- ordered after it there -- started at 64 s and the display connected at 83 s instead of about 35 s. On the alpha channel nearly every boot is a post-update boot. The two detached runs (arco-reconcile from ensure-imageid.sh, arco-guard-repair-run from repair-guards.sh) now start with nice 19 and idle I/O. Nothing waits on either: both take effect on the next start, so they can yield to everything that does. arco-console-filters.service was a Type=oneshot with three ExecStart= lines, and a oneshot under multi-user.target holds "Startup finished" until it exits: 22.9 s of 82 s on a printer with nothing left to seed. It is now Type=simple with the one ExecStart that shape allows, apply-web-seeds.sh, which runs the same three seeds in the same order with the same tolerance. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
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
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.
Symptom: since the guard set went live, the display comes up 30–50 s later than it used to.
Measured 2026-09-05 on the dev printer (seconds after power-on): the 12 klipper guards 17→26, klippy ready 28.6; Spoolman 18→64 (34 s Python start, 8 s migrations);
optimize-boot.shrunning in the background 19→80 asarco-reconcileafter the #124 update; Moonraker only from 64, server ready 83; voronFDM starts at 64 and can connect at 83;arco-console-filters64→87 holdingmulti-user.target.The Spoolman ordering is that printer's personal unit and not the kit's business. What is the kit's:
optimize-boot.shruns (arco-reconcilefromensure-imageid.sh,arco-guard-repair-runfromrepair-guards.sh) now start with--nice=19 -p IOSchedulingClass=idle. Nothing waits on them; both take effect on the next start.arco-console-filters.serviceisType=simplewith a singleExecStart, the newscripts/apply-web-seeds.sh, which runs the same three seeds in the same order and with the same tolerance the threeExecStart=lines had. A oneshot undermulti-user.targetheld "Startup finished" for the whole poll.Not changed, worth knowing: the 22
daemon-reloads insideoptimize-boot.shrun in PID 1 and are not affected by nice; a follow-up could batch them.Checks:
bash -non all four scripts, ShellCheck error-severity clean, no other script depends on the old unit shape (grepoverscripts/and.github/).🤖 Generated with Claude Code