Re: [rdiff-backup-users] rdiff-backup 1.1.17 released

[Andrew Ferguson]

On Jul 21, 2008, at 12:19 AM, Oliver Hookins wrote:

> On Fri Jul 18, 2008 at 15:38:33 +1000, Oliver Hookins wrote:
> > On Thu Jul 17, 2008 at 09:09:40 -0400, Andrew Ferguson wrote:
> >
> > > The plan is to release this version as a new stable branch, 1.2.0 in
> > > about ten days.
> > >
> > > Before then, I am interested in exploring the SELinux issue and  
> > > Oliver
> > > Hookins' problems. With respect to SELinux, rdiff-backup just relies
> > > upon Python's distutils to build the libraries, so it will require  
> > > some
> > > digging to see why the SELinux chcon command is needed.
> >
> > Well I'm happy to provide any diagnostic information you would like  
> > to aid
> > with this. Part of the problem to me seems like there is no logging  
> > on the
> > client side - so if something goes wrong that isn't communicated to  
> > the
> > server you have a difficult time finding out what went wrong. But I  
> > guess
> > this wouldn't be trivial to implement.
>
> This is very bizarre, a handful of my machines all failed the backup  
> last
> night with the same error which is one I haven't seen before:
>
> Traceback (most recent call last):
>  File "/usr/bin/rdiff-backup", line 23, in ?
>    rdiff_backup.Main.error_check_Main(sys.argv[1:])
>  File "/usr/lib64/python2.4/site-packages/rdiff_backup/Main.py",  
> line 302,
> in error_check_Main
>    try: Main(arglist)
>  File "/usr/lib64/python2.4/site-packages/rdiff_backup/Main.py",  
> line 319,
> in Main
>    rps = map(SetConnections.cmdpair2rp, cmdpairs)
>  File "/usr/lib64/python2.4/site-packages/rdiff_backup/ 
> SetConnections.py",
> line 76, in cmdpair2rp
>    if cmd: conn = init_connection(cmd)
>  File "/usr/lib64/python2.4/site-packages/rdiff_backup/ 
> SetConnections.py",
> line 146, in init_connection
>    check_connection_version(conn, remote_cmd)
>  File "/usr/lib64/python2.4/site-packages/rdiff_backup/ 
> SetConnections.py",
> line 154, in check_connection_version
>    try: remote_version = conn.Globals.get('version')
>  File "/usr/lib64/python2.4/site-packages/rdiff_backup/ 
> connection.py", line
> 447, in __call__
>    return apply(self.connection.reval, (self.name,) + args)
>  File "/usr/lib64/python2.4/site-packages/rdiff_backup/ 
> connection.py", line
> 367, in reval
>    result = self.get_response(req_num)
>  File "/usr/lib64/python2.4/site-packages/rdiff_backup/ 
> connection.py", line
> 314, in get_response
>    try: req_num, object = self._get()
>  File "/usr/lib64/python2.4/site-packages/rdiff_backup/ 
> connection.py", line
> 239, in _get
>    data = self._read(length)
>  File "/usr/lib64/python2.4/site-packages/rdiff_backup/ 
> connection.py", line
> 209, in _read
>    try: return self.inpipe.read(length)
> OverflowError: requested number of bytes is more than a Python  
> string can
> hold
> Fatal Error: Lost connection to the remote system
>
> Any ideas about this one?


Oh, I think I've seen this before. I believe you have made a  
configuration mistake with your shell or some such -- I believe that  
rdiff-backup is not being found in the path and starting properly. You  
should manually SSH in and see what's going on. Also, the ' -v9 '  
option might help.

That traceback indicates that rdiff-backup on the source side has  
asked the destination side for its version number. The destination  
side responded with something entirely bogus. I seem to recall seeing  
that happen when rdiff-backup was not properly setup on the  
destination side. Instead of rdiff-backup running like usual, the  
shell had responded with "Can't find rdiff-backup, please ask the  
system administrator" or some non-sense like that.


Andrew