Submit Hint Search The Forums LinksStatsPollsHeadlinesRSS
14,000 hints and counting!


Click here to return to the 'rsync vs. rdist' hint
The following comments are owned by whoever posted them. This site is not responsible for what they say.
rsync vs. rdist
Authored by: Fil Machi on Sep 30, '03 08:24:28PM

A little warning. The the article referenced above (clicky), gives a flawed method for creating a lock file to prevent two or more instances of rsync from running simulateously, "to avoid data corruption" according to the author.

That method only works some of the time. In other words, it depends on a race condition and so can result in two or more instances of rsync running simultaneously, exactly what the author of that script was trying to avoid.

In fact, Listing 3 of that article is a good example of how NOT to do file locking using files.

The race condition is in this code (taken from the article):

if [ -f $LOCK ]; then
        echo "Rsync failed on ${SYSTEM} -- lock in place."
        exit
fi

touch $LOCK
rsync -r --delete $SOURCE $DEST

There is no way to ensure that after testing for the existence of the lock file (-f $LOCK), the same instance of the script will get to immediately create the lock file (touch $LOCK). The OS is free to switch to another instance of the same script that someone else (or cron) may have started at about the same time. This second instance could get to test and create the lock file before the OS resumes the first instance. When the first script resumes, it will blindly continue where it left off and create the lock file, regardless of whether it was just created by the second instance. Both instances would believe they own the lock and both would go on to run the rsync command.

Better to use a locking method based on an atomic filesystem operation such as creating a hard link. Just a heads up to the unsuspecting.



[ Reply to This | # ]