mirror of
https://github.com/Klipper4FlashForge/firmware.git
synced 2026-10-21 12:52:16 -05:00
Oleksandr ShyshatskyiandClaude Opus 5
e3d5a62860
sntpd and ntpclient are one binary that picks its argument parser from
argv[0], and only one of those parsers can step the clock. The step is behind
if (!dry && ntpc->set_clock) sntpd.c:485
and set_clock is raised in exactly one place: `case 's'` in the ntpclient
parser, sntpd.c:1459. Under the sntpd name it is initialised to zero with no
option to raise it -- that parser's -s means "log to syslog" -- and the daemon
disciplines the clock FREQUENCY through adjtimex instead. Right for a clock
that is roughly correct and drifting; useless on a printer with no RTC, which
boots in 1970. Parts per million do not close fifty-six years.
So the service has never worked. It resolved, connected, took valid stratum-1
readings, logged a reading line every poll, and left the clock in 1970 for as
long as the machine was up -- healthy by every signal except the one that
matters.
The recipe asks for --with-ntpclient, which is upstream's own install hook and
a symlink rather than a second copy of the binary (asserted, because a cp that
dereferenced it would ship 32KB twice). The run script execs that name with
-s -l, and its option block is rewritten against the ntpclient parser: the two
disagree about -p, and -n does not exist there at all, so the old arguments
would have been a usage error and a service that exited at once.
Measured on a printer: clock forced back two hours, service restarted, correct
again twenty seconds later.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01AVUMfbNuKUWWV32PBcydwb