mirror of
https://github.com/Klipper4FlashForge/firmware.git
synced 2026-10-19 03:49:50 -05:00
Oleksandr ShyshatskyiandClaude Opus 5
2be2de2bc5
Two commits ago this script called s6-rc-update so a recompiled database
reached a running machine without a reboot. On the printer it does this, from
a live state that had just booted cleanly:
s6-rc-update: fatal: unable to manage new service directories
in /run/s6-rc: Value too large for defined data type
and by then every symlink under $MODDIR/etc/s6 is already gone, while the
s6-supervise processes it started are still running. Nothing looks wrong --
until the next s6-svscan rescan, which finds an empty scandir and takes down
klipper, the UI and wifi together. On a printer reached over that wifi, the
recovery is a power cycle.
So the database is compiled, `current` is moved, and the live state is left
alone. The cost is stated where it is paid: `s6-rc` reports "unable to read
valid state" until the next boot, because /run/s6-rc/state is one byte per
service in the database that booted and /run/s6-rc/compiled resolves through
`current`. Supervision is a separate mechanism and keeps every service up, so
the printer runs normally in the window.
s6-rc-update still ships. It is the right tool for a hand at a prompt, and the
EOVERFLOW wants finding first -- it is not the obvious missing largefile flag,
which skalibs, s6, execline and s6-rc all already pass.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01AVUMfbNuKUWWV32PBcydwb