make a cronjob wait for previous rsync job to finish

Solution 1:

You can implement some kind of locking. This will print the number of rsync processes still running:

pgrep -cx rsync

And this will run the rsync only if no other rsync process exists:

pgrep -cx rsync || rsync ...

Using -x will prevent from accidentally matching unwanted names (for example "foobarsynchronizator" or "not_an_rsync_totally" - it works just like pgrep -c ^rsync$)

Solution 2:

You can use the flock command to help you do this e.g. In this case flock -n is probably what you want as it will cause an immediate failure of the command if it can't obtain the lock e.g.

30 * * * *  /usr/bin/flock -n /tmp/myRsyncJob.lck /path/to/your/rsyncScript 

---

Solution 3:

Here is what I'd do. Create a wrapper script around the rsync to create a lock file.

script 1
- create lock file
- rsync
- remove lock file

script 2 (running later then script 1)
- check if lock file is there
    - if not run
    - if it is there wait 10 minutes in a loop. break out of lopp when the lock file is gone
- continue to run script

---

Solution 4:

If you're willing to consider other tools, you could also have a look at rdiff-backup. It uses librsync to do backups, and saves a configurable number of deltas/increments. It also locks so that only one rdiff-backup process can run at any given time.

---

Solution 5:

My Answer is somewhat same what Mike told.

In the script, you should put something like this:

• create a lock file
• Check for the existence of the lock file when you run it next time.

But there is one very important thing you should be doing. and that to implement a trap system.

So, with that, what you can do, is that even if somehow your script is killed or someone killed it, then you can trap that signal and remove the lock file, so that you don't have a stale lock file.

You can read how to implement that over here.

Just one small thing, you can't trap signal 9, I mean if someone do kill -9, you can't trap that as that signal directly interacts with the kernel and there is no way to trap that.

Also, as suggested by John, you need to remove the lock file everytime your system reboots, just to make sure that there is no stale file left.

That you can easily do by putting a small rm -f <FILE> command in /etc/rc.local