rsyncing *to* live system

jw schultz jw at
Wed Aug 27 08:19:39 EST 2003

Please do not start a new topic/thread by doing a reply or
followup to a previous post.  Doing so buries your message
in an unrelated thread.

On Wed, Aug 27, 2003 at 09:25:41AM +1200, Steve Wray wrote:
> Hi there,
> I have been asked to develop a system for keeping
> a bunch of machines remotely configured and updated.
> The client has asked for this to be implemented using rsync.
> The machines involved are located at remote sites and
> physical access by competent personel is non trivial.
> And the systems are running Debian.
> I am a little concerned at the prospect of using rsync to
> replace running binaries, open files and system libraries.
> I've searched for an example where rsync has been used in this way.
> So far I have found nothing; people use it to backup a live
> filesystem; we are tasked with doing the reverse (sort of).
> And there are people who use rsync to replicate systems (rolling out
> a bunch of identical boxes; typically these recieve the rsync
> *before* they go live not after).
> So, can anyone please give me arguments or reasons for
> or against using rsync in this way? References to sites
> which currently use rsync in this way would be much appreciated.

There are some difficulties that can occur depending on how
you structure your filesystems.

It is possible to produce temporary dangling symlinks.
Rsync may remove the destination of the link before
the symlink is updated or deleted (see --delete-after); or
if rsync creates or updates a symlink before the destination
is created.

You can get inter-file inconsistencies.  The file sets are not
updated atomically so different config files and binaries
may be updated at slightly different times.  Because rsync
processes the file list in lexical order the window size will
depend on the relative remoteness of files in the directory
hierarchy so files in the same directory have small windows
but files in different subtrees will have a somewhat larger

If an program consults config files or loads plugins from
files not kept open since initialisation it is remotely
possible to get version mismatch between the running
program and the files it opens subsequent to the rsync.
In such a case you would want to bounce the running program.

I am not aware of any other issues affecting local

Rsync works by creating a new file and then replacing the
old with it.  It does not overwrite the old file.  This
means that open file descriptors (including running
executables) will continue to reference the old version
which will not be physically deleted from disk until all
references to it close.  Stateless network filesystems (such
as NFS and samba) generally don't have this protection
although nfs's silly-rename may mitigate this in some

	J.W. Schultz            Pegasystems Technologies
	email address:		jw at

		Remember Cernan and Schmitt

More information about the rsync mailing list