1.40.3 — Retired units stay retired, schedules fire once

2026-10-28

The deploy that retires the old MojoSec resolver and audit-health units no longer rolls itself back, the sensor's FIM baseline cannot go stale under a mid-scan re-initialise, and @schedule(hours="3") fires once at 03:00 instead of every minute of hour 3. Deploy this before switching nodes to the al2023-web-v3 profiles.

Fixed

• The deploy that retires the old MojoSec resolver and audit-health units no longer rolls itself back: a unit without an [Install] section answers systemctl is-enabled with static, which the sweep read as "still enabled". Nodes deployed with 1.40.2 kept the 5-second health timer and a crash-looping resolver; this deploy removes them.
• A FIM baseline re-initialised from another process while the sensor was mid-scan can no longer leave the sensor diffing against stale memory and missing a deleted file. The baseline is cached under the stamp the sensor's own write produced, and a write whose baseline moved is refused and retried once.
• @schedule(hours="3") fires once at 03:00. An omitted finer field now resolves to 0 when a coarser one is named; a bare @schedule() is still every minute, and an explicit minutes="*" stays as written. Loading schedules warns, by function name, about any that still fires more than once an hour.
• A malformed schedule value is logged while schedules load instead of stopping the load; that schedule fails on its own tick as before.

Upgrade notes

• Deploy this before switching any node to the al2023-web-v3 / al2023-content-v2 profiles; the retired units go on this deploy.
• Check your own @schedule decorators: one that named an hour or day without minutes was firing every minute and now fires once. The load-time warning lists what changed.