{ "api_version": "1", "kind": "dse_post", "self": "https://update.dsesecurity.com/api/v1/posts/decide-whether-a-systemd-calendar-timer-should-catch-up-after-downtime/", "item": { "id": "https://update.dsesecurity.com/updates/decide-whether-a-systemd-calendar-timer-should-catch-up-after-downtime/", "slug": "decide-whether-a-systemd-calendar-timer-should-catch-up-after-downtime", "url": "https://update.dsesecurity.com/updates/decide-whether-a-systemd-calendar-timer-should-catch-up-after-downtime/", "alternate_urls": { "markdown": "https://update.dsesecurity.com/updates/decide-whether-a-systemd-calendar-timer-should-catch-up-after-downtime.md", "json": "https://update.dsesecurity.com/api/v1/posts/decide-whether-a-systemd-calendar-timer-should-catch-up-after-downtime/" }, "title": "Decide whether a systemd calendar timer should catch up after downtime", "summary": "Persistent scheduling can trigger missed work when the timer becomes active again.", "format": { "slug": "guide", "name": "Guide" }, "priority": { "slug": "info", "name": "Information" }, "featured": false, "image": { "theme": "network-infrastructure", "label": "Networks & infrastructure", "alt": "Resilient network core with engineered blue and gold data paths.", "card_url": "https://update.dsesecurity.com/assets/editorial/network-infrastructure-card.webp?v=1.8.20", "hero_url": "https://update.dsesecurity.com/assets/editorial/network-infrastructure-hero.webp?v=1.8.20", "social_url": "https://update.dsesecurity.com/assets/editorial/network-infrastructure-social-v2.jpg?v=1.8.20", "width": 2400, "height": 1350 }, "topics": [ { "slug": "it", "name": "IT", "url": "https://update.dsesecurity.com/topic/it/" }, { "slug": "networks-infrastructure", "name": "Networks & Infrastructure", "url": "https://update.dsesecurity.com/topic/networks-infrastructure/" } ], "author": { "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/#editorial-team", "type": "Organization" }, "publisher": { "name": "Detection Systems & Engineering", "url": "https://dsesecurity.com/" }, "published_at": "2026-10-20T18:15:23+00:00", "modified_at": "2026-10-20T18:34:33+00:00", "reviewed_on": "2026-10-20", "reading_minutes": 2, "word_count": 269, "potentially_affected": "Review Persistent catch-up for OnCalendar timers using the Debian trixie systemd.timer manual.", "dse_recommendation": "DSE recommends choosing catch-up behavior with the task owner.", "primary_source": { "name": "Debian systemd manual — systemd.timer(5) — systemd — Debian trixie — Debian Manpages", "url": "https://manpages.debian.org/trixie/systemd/systemd.timer.5.en.html", "published_on": null, "authority": "manpages.debian.org" }, "publishing_principles": "https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/", "usage_info": "https://update.dsesecurity.com/usage/", "copyright_notice": "Copyright © 2026 Detection Systems & Engineering. All rights reserved.", "content_html": "

Persistent scheduling can trigger missed work when the timer becomes active again.

\n

Source facts

\n

The Debian systemd.timer manual states that Persistent stores the last trigger time on disk. When reactivated, a calendar timer can immediately trigger work that would have run while it was inactive. This behavior applies to OnCalendar timers and remains subject to RandomizedDelaySec. It is a catch-up mechanism rather than replay of every missed occurrence.

\n

Source: Debian systemd manual — systemd.timer(5) — systemd — Debian trixie — Debian Manpages.

\n

Applicability

\n

Review Persistent catch-up for OnCalendar timers using the Debian trixie systemd.timer manual.

\n

DSE recommendation

\n

DSE recommends choosing catch-up behavior with the task owner. A missed inventory reconciliation and a time-sensitive external notification may need different policies. Make the service idempotent where repeated execution is possible, and define whether stale work should be skipped by the application. Keep the persisted state in the timer’s retirement procedure. Account for random delay when explaining why an activated timer has not yet started work, and monitor successful completion separately from the presence of a scheduled trigger.

\n

Verification

\n

In a nonproduction timer, disable activity across a scheduled occurrence and then reactivate it. Compare behavior with the intended Persistent setting and inspect the next trigger and service result. Confirm the application handles a delayed execution appropriately without claiming every missed interval was individually processed. Retain the timer’s timestamp state, configured random delay and actual task result together. Ask the task owner to approve delayed execution explicitly, including the rule for rejecting stale business work when that is necessary.

\n

Official reference

\n

Debian systemd manual — systemd.timer(5) — systemd — Debian trixie — Debian Manpages. Reviewed October 20, 2026.

", "content_text": "Persistent scheduling can trigger missed work when the timer becomes active again.\nSource facts\nThe Debian systemd.timer manual states that Persistent stores the last trigger time on disk. When reactivated, a calendar timer can immediately trigger work that would have run while it was inactive. This behavior applies to OnCalendar timers and remains subject to RandomizedDelaySec. It is a catch-up mechanism rather than replay of every missed occurrence.\nSource: Debian systemd manual — systemd.timer(5) — systemd — Debian trixie — Debian Manpages.\nApplicability\nReview Persistent catch-up for OnCalendar timers using the Debian trixie systemd.timer manual.\nDSE recommendation\nDSE recommends choosing catch-up behavior with the task owner. A missed inventory reconciliation and a time-sensitive external notification may need different policies. Make the service idempotent where repeated execution is possible, and define whether stale work should be skipped by the application. Keep the persisted state in the timer’s retirement procedure. Account for random delay when explaining why an activated timer has not yet started work, and monitor successful completion separately from the presence of a scheduled trigger.\nVerification\nIn a nonproduction timer, disable activity across a scheduled occurrence and then reactivate it. Compare behavior with the intended Persistent setting and inspect the next trigger and service result. Confirm the application handles a delayed execution appropriately without claiming every missed interval was individually processed. Retain the timer’s timestamp state, configured random delay and actual task result together. Ask the task owner to approve delayed execution explicitly, including the rule for rejecting stale business work when that is necessary.\nOfficial reference\nDebian systemd manual — systemd.timer(5) — systemd — Debian trixie — Debian Manpages. Reviewed October 20, 2026.", "content_markdown": "Persistent scheduling can trigger missed work when the timer becomes active again.\n\n## Source facts\n\nThe Debian systemd.timer manual states that Persistent stores the last trigger time on disk. When reactivated, a calendar timer can immediately trigger work that would have run while it was inactive. This behavior applies to OnCalendar timers and remains subject to RandomizedDelaySec. It is a catch-up mechanism rather than replay of every missed occurrence.\n\nSource: [Debian systemd manual — systemd.timer(5) — systemd — Debian trixie — Debian Manpages](https://manpages.debian.org/trixie/systemd/systemd.timer.5.en.html).\n\n## Applicability\n\nReview Persistent catch-up for OnCalendar timers using the Debian trixie systemd.timer manual.\n\n## DSE recommendation\n\nDSE recommends choosing catch-up behavior with the task owner. A missed inventory reconciliation and a time-sensitive external notification may need different policies. Make the service idempotent where repeated execution is possible, and define whether stale work should be skipped by the application. Keep the persisted state in the timer’s retirement procedure. Account for random delay when explaining why an activated timer has not yet started work, and monitor successful completion separately from the presence of a scheduled trigger.\n\n## Verification\n\nIn a nonproduction timer, disable activity across a scheduled occurrence and then reactivate it. Compare behavior with the intended Persistent setting and inspect the next trigger and service result. Confirm the application handles a delayed execution appropriately without claiming every missed interval was individually processed. Retain the timer’s timestamp state, configured random delay and actual task result together. Ask the task owner to approve delayed execution explicitly, including the rule for rejecting stale business work when that is necessary.\n\n## Official reference\n\n[Debian systemd manual — systemd.timer(5) — systemd — Debian trixie — Debian Manpages](https://manpages.debian.org/trixie/systemd/systemd.timer.5.en.html). Reviewed October 20, 2026." }, "json_ld": { "@context": "https://schema.org", "@graph": [ { "@type": "Organization", "@id": "https://dsesecurity.com/#organization", "name": "Detection Systems & Engineering", "alternateName": "DSE Security", "url": "https://dsesecurity.com/", "logo": { "@type": "ImageObject", "url": "https://update.dsesecurity.com/assets/dse-logo-20260812.png?v=1.8.20" } }, { "@type": "Organization", "@id": "https://update.dsesecurity.com/#editorial-team", "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/", "parentOrganization": { "@id": "https://dsesecurity.com/#organization" } }, { "@type": "WebSite", "@id": "https://update.dsesecurity.com/#website", "name": "DSE Updates", "alternateName": "DSE Security Knowledge Hub", "url": "https://update.dsesecurity.com/", "inLanguage": "en-US", "publisher": { "@id": "https://dsesecurity.com/#organization" }, "potentialAction": { "@type": "SearchAction", "target": { "@type": "EntryPoint", "urlTemplate": "https://update.dsesecurity.com/?q={search_term_string}" }, "query-input": "required name=search_term_string" } }, { "@type": "WebPage", "@id": "https://update.dsesecurity.com/updates/decide-whether-a-systemd-calendar-timer-should-catch-up-after-downtime/", "url": "https://update.dsesecurity.com/updates/decide-whether-a-systemd-calendar-timer-should-catch-up-after-downtime/", "isPartOf": { "@id": "https://update.dsesecurity.com/#website" }, "lastReviewed": "2026-10-20" }, { "@type": "BreadcrumbList", "@id": "https://update.dsesecurity.com/updates/decide-whether-a-systemd-calendar-timer-should-catch-up-after-downtime/#breadcrumbs", "itemListElement": [ { "@type": "ListItem", "position": 1, "name": "DSE Updates", "item": "https://update.dsesecurity.com/" }, { "@type": "ListItem", "position": 2, "name": "IT", "item": "https://update.dsesecurity.com/topic/it/" }, { "@type": "ListItem", "position": 3, "name": "Decide whether a systemd calendar timer should catch up after downtime", "item": "https://update.dsesecurity.com/updates/decide-whether-a-systemd-calendar-timer-should-catch-up-after-downtime/" } ] }, { "@type": [ "Article", "TechArticle" ], "@id": "https://update.dsesecurity.com/updates/decide-whether-a-systemd-calendar-timer-should-catch-up-after-downtime/#article", "identifier": "https://update.dsesecurity.com/updates/decide-whether-a-systemd-calendar-timer-should-catch-up-after-downtime/", "url": "https://update.dsesecurity.com/updates/decide-whether-a-systemd-calendar-timer-should-catch-up-after-downtime/", "headline": "Decide whether a systemd calendar timer should catch up after downtime", "description": "Persistent scheduling can trigger missed work when the timer becomes active again.", "abstract": "Persistent scheduling can trigger missed work when the timer becomes active again.", "articleBody": "Persistent scheduling can trigger missed work when the timer becomes active again.\nSource facts\nThe Debian systemd.timer manual states that Persistent stores the last trigger time on disk. When reactivated, a calendar timer can immediately trigger work that would have run while it was inactive. This behavior applies to OnCalendar timers and remains subject to RandomizedDelaySec. It is a catch-up mechanism rather than replay of every missed occurrence.\nSource: Debian systemd manual — systemd.timer(5) — systemd — Debian trixie — Debian Manpages.\nApplicability\nReview Persistent catch-up for OnCalendar timers using the Debian trixie systemd.timer manual.\nDSE recommendation\nDSE recommends choosing catch-up behavior with the task owner. A missed inventory reconciliation and a time-sensitive external notification may need different policies. Make the service idempotent where repeated execution is possible, and define whether stale work should be skipped by the application. Keep the persisted state in the timer’s retirement procedure. Account for random delay when explaining why an activated timer has not yet started work, and monitor successful completion separately from the presence of a scheduled trigger.\nVerification\nIn a nonproduction timer, disable activity across a scheduled occurrence and then reactivate it. Compare behavior with the intended Persistent setting and inspect the next trigger and service result. Confirm the application handles a delayed execution appropriately without claiming every missed interval was individually processed. Retain the timer’s timestamp state, configured random delay and actual task result together. Ask the task owner to approve delayed execution explicitly, including the rule for rejecting stale business work when that is necessary.\nOfficial reference\nDebian systemd manual — systemd.timer(5) — systemd — Debian trixie — Debian Manpages. Reviewed October 20, 2026.", "datePublished": "2026-10-20T18:15:23+00:00", "dateModified": "2026-10-20T18:34:33+00:00", "mainEntityOfPage": { "@id": "https://update.dsesecurity.com/updates/decide-whether-a-systemd-calendar-timer-should-catch-up-after-downtime/" }, "inLanguage": "en-US", "isAccessibleForFree": true, "author": { "@type": "Organization", "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/#editorial-team" }, "publisher": { "@id": "https://dsesecurity.com/#organization" }, "image": { "@type": "ImageObject", "@id": "https://update.dsesecurity.com/updates/decide-whether-a-systemd-calendar-timer-should-catch-up-after-downtime/#primaryimage", "url": "https://update.dsesecurity.com/assets/editorial/network-infrastructure-social-v2.jpg?v=1.8.20", "contentUrl": "https://update.dsesecurity.com/assets/editorial/network-infrastructure-social-v2.jpg?v=1.8.20", "width": 1200, "height": 630, "caption": "Decide whether a systemd calendar timer should catch up after downtime" }, "articleSection": [ "IT", "Networks & Infrastructure" ], "keywords": [ "IT", "Networks & Infrastructure", "Guide", "Information priority" ], "genre": "Guide", "about": [ { "@type": "Thing", "name": "IT", "url": "https://update.dsesecurity.com/topic/it/" }, { "@type": "Thing", "name": "Networks & Infrastructure", "url": "https://update.dsesecurity.com/topic/networks-infrastructure/" } ], "wordCount": 269, "timeRequired": "PT2M", "publishingPrinciples": "https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/", "usageInfo": "https://update.dsesecurity.com/usage/", "copyrightHolder": { "@id": "https://dsesecurity.com/#organization" }, "copyrightNotice": "Copyright © 2026 Detection Systems & Engineering. All rights reserved.", "citation": { "@type": "CreativeWork", "name": "Debian systemd manual — systemd.timer(5) — systemd — Debian trixie — Debian Manpages", "url": "https://manpages.debian.org/trixie/systemd/systemd.timer.5.en.html" } } ] } }