Weekly Padgett

No. 0382 min read

Cron started the command. What the hell else did you expect?

Cron starts commands when the clock matches, folks. Dates, missed days, overlapping runs, and whether anything actually published are still our damned problem.

A desk holds an alarm clock, chicken drumstick, and service bell, with a computer and typewriter behind.
File photoDramatization. No cron was harmed.

Putting the publisher in cron[1]Ref. 1cron en.wikipedia.org still leaves a fair amount for us to do.

Cron is a scheduler. Any suggestion otherwise is unfair to cron, which matches a clock against a schedule and starts a command. It doesn't know yesterday's story remains unpublished or that the previous invocation is still working. A successful process exit might have produced precisely fuck-all of what you expected, and cron wouldn't know that either.

The grime95[2]Ref. 2grime95 grime95.com publisher has a particularly fun wrinkle: the fiction has dates. A booking dated in 1995 is story content. I appreciate 1995 as much as the next dinosaur, but we're not trying to publish something back into it.

The publisher README separates posting_date from the fictional date. Missing scheduling dates get skipped with a diagnostic. An explicitly malformed arrest-level scheduling date is an error. We can't just borrow another date because it looks convenient sitting over there.

The README's recovery behavior differs from my earlier publishing post, so I'd be careful about copying that. This documented variant selects a date and allows deliberate past-date replay. It explicitly says there is no automatic backlog publishing. I'm discussing that contract here; I haven't established that my earlier description matches whatever is installed now.

Traditional cron doesn't keep a durable queue[3]Ref. 3durable queue en.wikipedia.org of scheduled invocations while the host is off. Miss the minute and ordinary cron doesn't wake up later and work out which business work you meant to recover.

In the documented grime95 interface, you start with an explicit date and a dry run[4]Ref. 4dry run en.wikipedia.org, inspect the selection, then authorize publication. I'd keep that calendar argument visible in the command and the logs. It belongs in any recovery note too, since the next person needs to know which yesterday I meant.

Before enabling the schedule, I'd deliberately miss a run and rehearse recovery. I'd want to be able to explain which date publishes next before leaving it alone.

References

  1. cron en.wikipedia.org ↩
  2. grime95 grime95.com ↩
  3. durable queue en.wikipedia.org ↩
  4. dry run en.wikipedia.org ↩

More on this beat