Developer tools · Crontab generator
anacron and cron.daily: how scheduled jobs survive a machine being off
· Background
cron reliability scheduling
cron assumes the machine is always on; anacron does not. This post explains how anacron tracks the last run, how Debian-style cron.daily directories use it, and how to pick between the two.
A sleeping machine scenario is outside the browser; the preview only searches future candidates
ToolAcre cannot observe whether a laptop slept through 06:25. Its next-run function receives a starting instant and searches strictly forward, beginning one minute later. Earlier matching minutes are not returned because the feature is a future preview, not a history or recovery engine.
That makes the list useful for planning but silent about catch-up. A missing past candidate may have run, been skipped or been handled by another service; the browser has no execution record. Diagnose downtime behavior from the installed scheduler rather than from absence in a future-only list.
External cron missed-run behavior is not established here
The workbook asserted that cron discards missed minutes. No daemon implementation or uptime test is part of this repository, so the universal claim is not repeated. What is proven is that ToolAcre itself does not queue jobs: it calculates dates in memory and returns them to the page.
A target scheduler may document a missed-run policy, and a wrapper may add another. Capture that policy explicitly. The same `0 6 * * *` expression can participate in different recovery designs without changing any of its five values.
anacron state and delays are not implemented
There is no anacron timestamp file, period counter or startup delay in `cron.js`. The parser knows calendar fields, while the preview knows a configurable search horizon. Neither stores when an external action last completed.
Therefore this article cannot explain anacron’s exact state transitions from project evidence. If catch-up is required, research and test the actual facility. ToolAcre may still construct any precise-time cron lines retained alongside it, but it cannot validate an anacron policy.
anacrontab syntax is outside the five-field parser
An anacrontab row is not a five-field cron expression. Feeding its period, delay and identifier into ToolAcre would fail field count or value validation without teaching anything about its real syntax. Similar scheduling goals do not imply interchangeable file formats.
Keep native validators with native grammar. Use this route for minute-through-weekday expressions and a separate source for period-based catch-up configuration. Translation should preserve the operational requirement, not merely force one text form through another parser.
cron.daily wiring cannot be inferred from this repository
Directory mechanisms and handoffs between packages are absent from the codebase under review. The generator cannot know whether `/etc/cron.daily` exists, which runner invokes it or what happens when another package is installed. Any such wiring is environment-specific evidence.
Inventory the target before moving a task. A directory name alone does not reveal wall-clock time or catch-up behavior. Compare observed service configuration with the requirement, and retain the ToolAcre expression only if the job genuinely remains in a compatible cron path.
Worked boundary: compare future candidates without promising catch-up
For a daily example, enter `0 6 * * *` and select the deployment zone. The preview lists up to five future 06:00 wall-clock candidates after now. If the start instant is already past today’s 06:00, tomorrow becomes the first result. That is forward-search behavior, not evidence of what happened this morning.
Use the list to check calendar intent and zone conversion. Then power-cycle or suspend a safe test environment across a scheduled time and observe the actual scheduler’s policy. The two experiments answer different questions and should remain separately documented.
Persistent timer behavior is unverified and omitted
The workbook mentioned a persistent setting in another service manager. No unit parser or test supports that statement here. It may be relevant external research, but this module does not turn it into a recommendation without authoritative source material.
A missed-run requirement deserves explicit acceptance criteria: whether to run immediately, skip, coalesce or preserve every occurrence. Select a system that documents the needed result and verify it. ToolAcre can provide the cron cadence used as a baseline, nothing more.
Takeaway: pair a schedule with a separately verified missed-run policy
A recurring expression is incomplete as a reliability design if the machine may be unavailable. Calendar matching and catch-up policy are separate. ToolAcre exposes the former and intentionally has no persisted execution state for the latter.
Preview the future, record the zone and then test missed-run behavior on the destination. If another mechanism owns recovery, document that beside the expression. Avoid saying the generator or the five fields guarantee a retry, because neither can observe that a run was missed.