Source: Review discussion on PR #76 (fix for #59).
Category: robustness · Severity: low · Effort: small
Problem
PR #76 fixed packaging/install.sh so that pimonitor.service gets an explicit systemctl restart on upgrade, since systemctl enable --now is a no-op when the unit is already active and would otherwise leave a stale process/config running.
The same latent issue applies to pimonitor-apt-update.timer (install.sh:88): it's also only ever enable --now'd, never restarted. This is harmless today because the timer's schedule is static, but if a future release changes packaging/pimonitor-apt-update.timer (e.g. a different refresh interval), re-running the installer on a host where the timer is already active would install the new unit file but keep the old schedule loaded until an unrelated restart/reboot — the same class of bug as #59, just not yet triggered because nothing has changed the timer definition.
Suggested fix
Apply the same pattern used for pimonitor.service in #76/PR #76: capture whether pimonitor-apt-update.timer was already active before daemon-reload/enable --now, and explicitly systemctl restart pimonitor-apt-update.timer afterwards if so (restarting a .timer unit reloads its schedule without needing to touch pimonitor-apt-update.service, which only runs on the timer's own cadence anyway).
Source: Review discussion on PR #76 (fix for #59).
Category: robustness · Severity: low · Effort: small
Problem
PR #76 fixed
packaging/install.shso thatpimonitor.servicegets an explicitsystemctl restarton upgrade, sincesystemctl enable --nowis a no-op when the unit is already active and would otherwise leave a stale process/config running.The same latent issue applies to
pimonitor-apt-update.timer(install.sh:88): it's also only everenable --now'd, never restarted. This is harmless today because the timer's schedule is static, but if a future release changespackaging/pimonitor-apt-update.timer(e.g. a different refresh interval), re-running the installer on a host where the timer is already active would install the new unit file but keep the old schedule loaded until an unrelated restart/reboot — the same class of bug as #59, just not yet triggered because nothing has changed the timer definition.Suggested fix
Apply the same pattern used for
pimonitor.servicein #76/PR #76: capture whetherpimonitor-apt-update.timerwas already active beforedaemon-reload/enable --now, and explicitlysystemctl restart pimonitor-apt-update.timerafterwards if so (restarting a.timerunit reloads its schedule without needing to touchpimonitor-apt-update.service, which only runs on the timer's own cadence anyway).