Issue
start_systemd only rewrites the pond-sync.service/.timer unit when the user re-runs pond schedule start (or pond init). A plain binary upgrade does not refresh the unit, so an existing Linux user keeps the OLD ExecStart=.../pond sync -q - no --no-wait, no Environment=XDG_STATE_HOME.
Observed on bl (Ubuntu 24.04): the deployed unit is ExecStart=/home/linuxbrew/.linuxbrew/bin/pond sync -q. Stale but not broken (sync -q still runs); it just misses the single-flight skip and the pinned state dir until re-registered.
Action
Release-note for the version carrying #90: Linux users with an active pond schedule should run pond schedule start once after upgrading to pick up --no-wait and the state-dir pin. Optionally, pond schedule status could detect a stale unit format and hint the re-register.
Found during Linux verification of #90.
Issue
start_systemdonly rewrites thepond-sync.service/.timerunit when the user re-runspond schedule start(orpond init). A plain binary upgrade does not refresh the unit, so an existing Linux user keeps the OLDExecStart=.../pond sync -q- no--no-wait, noEnvironment=XDG_STATE_HOME.Observed on
bl(Ubuntu 24.04): the deployed unit isExecStart=/home/linuxbrew/.linuxbrew/bin/pond sync -q. Stale but not broken (sync -qstill runs); it just misses the single-flight skip and the pinned state dir until re-registered.Action
Release-note for the version carrying #90: Linux users with an active
pond scheduleshould runpond schedule startonce after upgrading to pick up--no-waitand the state-dir pin. Optionally,pond schedule statuscould detect a stale unit format and hint the re-register.Found during Linux verification of #90.