The robotic precision of cron ensures that each subsequent job runs, on time, every time.

But cron doesn’t check that the previous execution of that same job completed first — and that can cause big trouble.

This often happens to me when I’m traveling and my backup cronjob fires while I’m on a slow up-link.  It’s bad news when an hourly rsync takes longer than an hour to run, and my system heads down a nasty spiral, soon seeing 2 or 3 or 10 rsync‘s all running simultaneously.  Dang.

For this reason, I found myself putting almost all of my cronjobs in a wrapper script, managing and respecting a pid file lock according to the typical UNIX sysvinit daemon method.  Unfortunately, this led to extensively duplicated lock handling code spread across my multiple workstations and servers.

From the Canyon Edge – :-Dustin Kirkland: Introducing: run-one and run-this-one.