RERR_PARTIAL exit status

[Keith Hellman]

Hello all, long first post, sorry.

I've been using rsync in a backup script for several years now.  The
script has been stable, and the backup system as a whole pretty much
error free for at least 2 years, the only hiccups being minor tweaks to
accommodate changes to base utilities used (lvm, namely).

In broad strokes, here is what happens for the home directory on my
notebook(s).
  0. lvcreate(8) is used to create a 128MB read-only snapshot of my
     ${HOME}.  It is mounted at /mnt/snapshots/khellman
  1. ssh-agent(1) is used with a passphrase-less identity file to setup
     an environment for pushing data to my home server
  2. my script is invoked, it traverses /mnt/snapshots/khellman creating a
     list of files to be pushed to the remove server.
  3. the push happens and all the environments are shutdown in reverse
     order

Pertinent details of the backup are logged to a file in my HOME.  This
has been my setup for at least 2 or 3 years now.  I've been very happy
with its performance.

The rsync version reported on all machines is 3.0.7 from the debian
testing package of the same version (see attached lis).

As of late, all the pushes to my home server end up with rsync exiting
with code 23 (RERR_PARTIAL).  I can't quite reconcile why this is.

  * Backing up from /mnt/snapshots/khellman means that the process
	creating the file list should see an immutable version of my HOME.
	If my fetchmail process runs from cron, it changes the logical
	volume contents mounted at my HOME, but /mnt/snapshots/khellman
	should not change.

  * Recently, I've revamped my home server using Linux software raid.
	But this is on the *destination* of the data flow, not only should
	changes to the underlying media be insulated from the rsync client
	on my notebook, my impression from the rsync code base is that
	RERR_PARTIAL is detected on the client, not the server.

  * My backup script supports multiple destinations for the data.  If
	I hook up my big external usb drive, turn my network off, I still
	get RERR_PARTIAL exit codes.  So this doesn't seem to be a network
	media or server setup issue (btw, my notebook, server, and usb drive
	all use the same file system type, ext3; the notebook and server
	both run debian testing).

  * I thought this might be an issue with LVM snapshots (new defect? not
	big enough anymore? a little bit of file meta data not being handled
	correctly?).  I've tested my back script with other LVM snapshots
	--- some exceedingly small (1/2 or 1 MB) with some extreme file
	twiddling on the write side, and I cannot raise the RERR_PARTIAL
	exit code.  Pretty basic file state inspection (using ls, du)
	doesn't show the snapshot failing either.  Despite this I've bumped
	my snapshot size to 8GB (was 128M) for my HOME.
  
I recently changed my backup script to invoke with rsync w/ -v -v and store
the output to (yet another) log file.  After a nightly backup I looked
at the results, and:
   
  1. removed all the lines ending in ' is uptodoate$'
  2. removed all the lines with a space (presumably a log message
	 causing RERR_PARTIAL would have a space in it)
  3. removed all the lines w/ ' [-=]> '

I was hoping to weasel this log file down to that singlular file that is
causing the RERR_PARTIAL exit code.  No dice.  All I saw were the
2 filenames I have with a space in them. :^(

So, my questions to the rsync community are:

  1. Am I correct in assuming that rsync *would* write something to
	 stdout or stderr when the RERR_PARTIAL condition is triggered?

  2. Have I missed a special flag that would detail why RERR_PARTIAL
     is the exit code?

  3. Any other suggestions to try?

TIA,
-- 
Keith Hellman                             #include <disclaimer.h>
khellman at mcprogramming.com                from disclaimer import standard
khellman at mines.edu
                                   -*-                                    
                    public key @ pgp.mit.edu 9FCF40FD 
    Y!M: mcprogramming                           AIM/ICQ: 485403897       
   gtalk (xmpp jabber): mrtuple at jabber.org, jabber at mcprogramming.com                      
                                   -*-                                    

"XML is widespread because [a] monumentally stupid standard is still better
than no standard."

-- Alex Belits http://tech.slashdot.org/comments.pl?sid=607491&cid=24105649
-------------- next part --------------
CLIENT
------
$ dpkl -l |grep rsync
ii  rsync                                           3.0.7-2                         fast remote file copy program (like rcp)

$ rsync --version
rsync  version 3.0.7  protocol version 30
Copyright (C) 1996-2009 by Andrew Tridgell, Wayne Davison, and others.
Web site: http://rsync.samba.org/
Capabilities:
    64-bit files, 64-bit inums, 64-bit timestamps, 64-bit long ints,
    socketpairs, hardlinks, symlinks, IPv6, batchfiles, inplace,
    append, ACLs, xattrs, iconv, symtimes

rsync comes with ABSOLUTELY NO WARRANTY.  This is free software, and you
are welcome to redistribute it under certain conditions.  See the GNU
General Public Licence for details.

SERVER
------
$ dpkl -l |grep rsync
ii  rsync                             3.0.7-2                      fast remote file copy program (like rcp)

$ rsync --version
rsync  version 3.0.7  protocol version 30
Copyright (C) 1996-2009 by Andrew Tridgell, Wayne Davison, and others.
Web site: http://rsync.samba.org/
Capabilities:
    64-bit files, 64-bit inums, 32-bit timestamps, 64-bit long ints,
    socketpairs, hardlinks, symlinks, IPv6, batchfiles, inplace,
    append, ACLs, xattrs, iconv, symtimes

rsync comes with ABSOLUTELY NO WARRANTY.  This is free software, and you
are welcome to redistribute it under certain conditions.  See the GNU
General Public Licence for details.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.samba.org/pipermail/rsync/attachments/20100617/6feb8cf8/attachment.pgp>