We used to run crons using a custom wrapper which handled locking, logging, state reporting and enable/disable via puppet. However, systemd timer units basically do all of this for you, so I'd recommend that instead.
If you use consul, you can use `consul lock` [0]. Allows you to have the cron configured on multiple servers too.<p>[0]: <a href="https://www.consul.io/commands/lock" rel="nofollow">https://www.consul.io/commands/lock</a>
OpenBSD's crontab provides a `-s command` flag which does similar thing in principle:<p><a href="https://man.openbsd.org/crontab.5" rel="nofollow">https://man.openbsd.org/crontab.5</a><p>"-s command<p>Only a single instance of command will be run concurrently. Additional instances of command will not be scheduled until the earlier one completes."<p>But I don't think it saves the state somewhere permanently, which isn't a big problem until cron's process dies for some reason.
A fairly common pattern would be trying to create a specifically named file with the O_CREAT and O_EXCL flags. That's atomic, so you don't need flock. If it fails, then exit. This pattern is also often extended where you write your pid to the file and subsequent runs do a sanity check that your pid is actually running, and unlink the file if not.<p>That said systemd-timers, as mentioned in many other comments, is probably the right answer here.
Huh, does python not have a way to flock a file itself?<p>A simple flock doesn't always work all that well - the devil is in the details. And there is the issue that you miss a run of the script and have to wait another half hour for the next run.<p>I've used the Highlander, "There can be only one!" code pattern for forever, and it works really well:<p><a href="https://www.perlmonks.org/?node_id=14260" rel="nofollow">https://www.perlmonks.org/?node_id=14260</a><p>You could change things to check on the status of your lock every minute or so for 15 minutes or whatever.<p>Also in module form,<p><a href="https://metacpan.org/pod/App::Highlander" rel="nofollow">https://metacpan.org/pod/App::Highlander</a><p>And much more updated:<p><a href="https://medium.com/booking-com-development/highlander-b6717278a457" rel="nofollow">https://medium.com/booking-com-development/highlander-b67172...</a><p>No need to attempt to stuff all this in a cronjob IMHO.
Welcome to Debian's dpkg::start-stop-daemon circa 2001<p><a href="https://git.dpkg.org/cgit/dpkg/dpkg.git/commit/utils/start-stop-daemon.c?id=d2c1c54171034f90ed4d3aba80b051f457fd569a" rel="nofollow">https://git.dpkg.org/cgit/dpkg/dpkg.git/commit/utils/start-s...</a>
Or install moreutils from your distro's package repo so you can use lckdo and get some other super useful shell helpers too.<p><a href="https://joeyh.name/code/moreutils/" rel="nofollow">https://joeyh.name/code/moreutils/</a>
I have made a simple "cron with extras" project <a href="https://github.com/umputun/cronn" rel="nofollow">https://github.com/umputun/cronn</a> handling duplication issue as well as a bunch of other things, like restarting failed jobs, jitter, automatic reload and so on.
How to use systemd timers as a replacement for cron jobs:
<a href="https://opensource.com/article/20/7/systemd-timers" rel="nofollow">https://opensource.com/article/20/7/systemd-timers</a>
Systemd is much more powerful than cron and manages your exact use case. You will need to deal with process hangs though if you have self dependencies like this.