Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #248006 > unrolled thread

rsync trying to load rdiff-backup

Back to article view | Back to linux.debian.user

Contents

  rsync trying to load rdiff-backup AC <debusersQ743@acarver.net> - 2022-05-08 23:30 +0200
    Re: rsync trying to load rdiff-backup David <bouncingcats@gmail.com> - 2022-05-09 01:50 +0200
      Re: rsync trying to load rdiff-backup AC <debusersQ743@acarver.net> - 2022-05-09 03:00 +0200
        Re: rsync trying to load rdiff-backup David <bouncingcats@gmail.com> - 2022-05-09 03:10 +0200
          Re: rsync trying to load rdiff-backup AC <debusersQ743@acarver.net> - 2022-05-09 03:30 +0200
            Re: rsync trying to load rdiff-backup AC <debusersQ743@acarver.net> - 2022-05-09 05:30 +0200

#248006 — rsync trying to load rdiff-backup

Due to some version mismatch issues I'm trying to switch over to rsync 
from rdiff-backup for backing up some files on my systems.

On most of them this has worked with no issue but I have one system that 
appears to be trying to load rdiff-backup whenever I run rsync:

root:~# /usr/bin/rsync testfile user@remote.host:testfile
Traceback (most recent call last):
   File "/usr/bin/rdiff-backup", line 20, in <module>
     import rdiff_backup.Main
ModuleNotFoundError: No module named 'rdiff_backup'
rsync: connection unexpectedly closed (0 bytes received so far) [sender]
rsync error: error in rsync protocol data stream (code 12) at io.c(235) 
[sender=3.1.3]


I don't understand why it's trying to load rdiff-backup, the traceback 
is a giveaway that it's running Python but I explicitly called out the 
path to rsync and I know it's not a python script:

root:~# less /usr/bin/rsync
"/usr/bin/rsync" may be a binary file.  See it anyway?
^?ELF^A^A^A^@^@^

This is all happening on Buster but I have three other Buster systems 
that ran with rdiff-backup and I can run rsync fine on them without 
rdiff-backup running.  What's the deal here?

[toc] | [next] | [standalone]

#248017

On Mon, 9 May 2022 at 07:24, AC <debusersQ743@acarver.net> wrote:
>
> Due to some version mismatch issues I'm trying to switch over to rsync
> from rdiff-backup for backing up some files on my systems.
>
> On most of them this has worked with no issue but I have one system that
> appears to be trying to load rdiff-backup whenever I run rsync:
>
> root:~# /usr/bin/rsync testfile user@remote.host:testfile
> Traceback (most recent call last):
>    File "/usr/bin/rdiff-backup", line 20, in <module>
>      import rdiff_backup.Main
> ModuleNotFoundError: No module named 'rdiff_backup'
> rsync: connection unexpectedly closed (0 bytes received so far) [sender]
> rsync error: error in rsync protocol data stream (code 12) at io.c(235)
> [sender=3.1.3]
>
> I don't understand why it's trying to load rdiff-backup, the traceback
> is a giveaway that it's running Python but I explicitly called out the
> path to rsync and I know it's not a python script:
>
> root:~# less /usr/bin/rsync
> "/usr/bin/rsync" may be a binary file.  See it anyway?
> ^?ELF^A^A^A^@^@^
>
> This is all happening on Buster but I have three other Buster systems
> that ran with rdiff-backup and I can run rsync fine on them without
> rdiff-backup running.  What's the deal here?

Hi, answering this might require knowledge of rdiff-backup, which I
don't have. But the first thing I would check is to compare the
/usr/bin/rsync file on the bad system with a good system.

Do you get the same output as my four commands below?

$ cat /etc/debian_version
11.3
$ rsync --version
rsync  version 3.2.3  protocol version 31
[...extra output elided...]
$ type rsync
rsync is hashed (/usr/bin/rsync)
$ md5sum /usr/bin/rsync
b09b45b5eb0ff5275805aadff1d0ed86  /usr/bin/rsync
$

[toc] | [prev] | [next] | [standalone]

#248020

On 2022-05-08 16:45, David wrote:
> On Mon, 9 May 2022 at 07:24, AC <debusersQ743@acarver.net> wrote:
>>
>> Due to some version mismatch issues I'm trying to switch over to rsync
>> from rdiff-backup for backing up some files on my systems.
>>
>> On most of them this has worked with no issue but I have one system that
>> appears to be trying to load rdiff-backup whenever I run rsync:
>>
>> root:~# /usr/bin/rsync testfile user@remote.host:testfile
>> Traceback (most recent call last):
>>     File "/usr/bin/rdiff-backup", line 20, in <module>
>>       import rdiff_backup.Main
>> ModuleNotFoundError: No module named 'rdiff_backup'
>> rsync: connection unexpectedly closed (0 bytes received so far) [sender]
>> rsync error: error in rsync protocol data stream (code 12) at io.c(235)
>> [sender=3.1.3]
>>
>> I don't understand why it's trying to load rdiff-backup, the traceback
>> is a giveaway that it's running Python but I explicitly called out the
>> path to rsync and I know it's not a python script:
>>
>> root:~# less /usr/bin/rsync
>> "/usr/bin/rsync" may be a binary file.  See it anyway?
>> ^?ELF^A^A^A^@^@^
>>
>> This is all happening on Buster but I have three other Buster systems
>> that ran with rdiff-backup and I can run rsync fine on them without
>> rdiff-backup running.  What's the deal here?
> 
> Hi, answering this might require knowledge of rdiff-backup, which I
> don't have. But the first thing I would check is to compare the
> /usr/bin/rsync file on the bad system with a good system.
> 
> Do you get the same output as my four commands below?
> 
> $ cat /etc/debian_version
> 11.3
> $ rsync --version
> rsync  version 3.2.3  protocol version 31
> [...extra output elided...]
> $ type rsync
> rsync is hashed (/usr/bin/rsync)
> $ md5sum /usr/bin/rsync
> b09b45b5eb0ff5275805aadff1d0ed86  /usr/bin/rsync
> $



Comparing the broken system with a good system:
debian_version matches: 10.12
rsync --version matches: rsync  version 3.1.3  protocol version 31
type matches: rsync is hashed (/usr/bin/rsync)
md5sum matches: 400d9c7e740e1ba06ebf779a7a10fc00  /usr/bin/rsync

As far as I can tell everything is identical but it seems that starting 
the rsync command somehow there is something intercepting and 
redirecting to execute rdiff-backup.


I went and compared all of my systems which had rdiff-backup installed. 
  All of them are Buster varying between 10.11 and 10.12 and a mix of 
them are having the same problem.  Three of the machines are 10.11, two 
work fine and the other is trying to look for rdiff-backup when running 
rsync.  The others are 10.12 with a similar issue, all of them are 
working except for one.  All the machines share similar configurations, 
usually a vanilla installation (no desktop environment) followed by 
whatever services each one needs (e.g. mail, ssh, etc.) and for 
something like backup they would all share the same configuration 
because they all run their backups to the same server.


Now here's a new discovery on the machines having problems: as a normal 
user I can rsync just fine to a remote machine.  But if I'm using rsync 
as root to send a backup to a remote machine, I get the rdiff-backup 
problem.  The other machines have no issues whether I'm a regular user 
or root.  What would change the behavior of a root user versus a regular 
user?

[toc] | [prev] | [next] | [standalone]

#248021

On Mon, 9 May 2022 at 10:53, AC <debusersQ743@acarver.net> wrote:
> On 2022-05-08 16:45, David wrote:
> > On Mon, 9 May 2022 at 07:24, AC <debusersQ743@acarver.net> wrote:

> Now here's a new discovery on the machines having problems: as a normal
> user I can rsync just fine to a remote machine.  But if I'm using rsync
> as root to send a backup to a remote machine, I get the rdiff-backup
> problem.  The other machines have no issues whether I'm a regular user
> or root.

Ok. In that case, I would run again the check commands I gave, but this
time as root, just to see if there is any difference.

I don't know the cause of your problem, but these commands are useful
investigation to reveal what "rsync" means when the particular user runs
that command.

[toc] | [prev] | [next] | [standalone]

#248022

On 2022-05-08 18:03, David wrote:
> On Mon, 9 May 2022 at 10:53, AC <debusersQ743@acarver.net> wrote:
>> On 2022-05-08 16:45, David wrote:
>>> On Mon, 9 May 2022 at 07:24, AC <debusersQ743@acarver.net> wrote:
> 
>> Now here's a new discovery on the machines having problems: as a normal
>> user I can rsync just fine to a remote machine.  But if I'm using rsync
>> as root to send a backup to a remote machine, I get the rdiff-backup
>> problem.  The other machines have no issues whether I'm a regular user
>> or root.
> 
> Ok. In that case, I would run again the check commands I gave, but this
> time as root, just to see if there is any difference.
> 
> I don't know the cause of your problem, but these commands are useful
> investigation to reveal what "rsync" means when the particular user runs
> that command.

All of my tests were done as root already.  They all matched.

[toc] | [prev] | [next] | [standalone]

#248031

On 2022-05-08 18:27, AC wrote:
> On 2022-05-08 18:03, David wrote:
>> On Mon, 9 May 2022 at 10:53, AC <debusersQ743@acarver.net> wrote:
>>> On 2022-05-08 16:45, David wrote:
>>>> On Mon, 9 May 2022 at 07:24, AC <debusersQ743@acarver.net> wrote:
>>
>>> Now here's a new discovery on the machines having problems: as a normal
>>> user I can rsync just fine to a remote machine.  But if I'm using rsync
>>> as root to send a backup to a remote machine, I get the rdiff-backup
>>> problem.  The other machines have no issues whether I'm a regular user
>>> or root.
>>
>> Ok. In that case, I would run again the check commands I gave, but this
>> time as root, just to see if there is any difference.
>>
>> I don't know the cause of your problem, but these commands are useful
>> investigation to reveal what "rsync" means when the particular user runs
>> that command.
> 
> All of my tests were done as root already.  They all matched.
> 


well I feel stupid but the problem ended up on the server side of this 
mess.  I had actually written command restrictions into the 
authorized_keys file on the server so that the unattended backups would 
use SSH keys that couldn't be used for anything else.  I did this ages 
ago and completely forgot about it.  The two machines that worked are 
brand new so they didn't have the keys set up and I was manually 
entering passwords when prompted just for testing.

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.user

csiph-web